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ABSTRACT 


The  fuel  planning  for  U.S.  naval  operations  at  sea  is  reactive  and  relies  upon  pen  and 
paper  calculations.  Decisions  on  where  and  when  to  refuel  are  complex  and  need  a 
Decision  Support  System  (DSS)  to  help  planners  maximize  the  benefits  of  the  limited 
fuel  resource.  This  thesis  defines  requirements  and  outlines  a  feasible  design  to  develop 
a  Naval  Fuel  Management  System  (NFMS).  The  variables  that  fuel  planning  rely  upon 
are  not  just  ship  course  and  speed,  but  also  the  weather  at  the  time  a  ship  travels  through 
a  particular  area.  The  most  efficient  plant  configuration  plays  a  factor  in  the  fuel  plan  as 
well.  Additionally,  there  are  numerous  ports  and  oilers  available  at  any  given  time.  Up- 
to-date  accurate  weather  forecast  databases  are  available,  predicting  currents  and  winds, 
which  will  affect  the  ship  in  the  future.  Fuel  bum  charts  have  been  developed  for  each 
ship  class  outlining  the  most  efficient  plant  configuration  for  given  speeds. 
Transportation  analysis  has  shown  that  an  optimal  path  exists  for  this  class  of  complex 
problems.  By  combining  these  technologies  into  one  system,  an  application  can  be 
developed  to  accurately  plan  fueling  operations  in  the  future,  making  Navy  refueling 
more  efficient. 
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EXECUTIVE  SUMMARY 


This  thesis  will  focus  on  identifying  the  requirements  and  generating  a  design  for  a 
Decision  Support  System  (DSS)  to  manage  the  Navy’s  fuel  usage  on  ships.  Current 
practices  to  determine  fueling  points  utilize  calculations  done  on  paper  using  paper  burn 
charts,  and  an  oversimplified  model,  the  Position  of  Intended  Movement  (PIM)  as  input 
variables.  Fueling  arrangements  are  made  either  on  a  periodic  basis  or,  at  most,  one  or 
two  weeks  before  the  intended  refueling  date.  The  periodic  refueling  schedule  wastes 
fuel  both  in  reaching  the  refueling  points,  and  steaming  on  all  main  engines  during  the 
refueling  process,  not  to  mention  the  incursion  of  port  fees  for  inport  refueling 
operations.  In  addition,  needlessly  refueling  removes  an  asset  from  station  for  the  time 
required  for  refueling.  The  periodic  schedule  wastes  man  hours  and  can  add  stress  to  a 
crew  already  dealing  with  high-tempo  operations  in  today’s  naval  environment. 

The  proposed  DSS  will  use  weather  data  in  conjunction  with  dynamic  and  stored 
fueling  points  to  facilitate  optimal  path  network  analysis  based  on  actual  conditions  rather 
than  an  oversimplified  PIM  model.  The  evaluation  will  be  used  to  identify  optimal  or 
near  optimal  tacks  to  follow.  It  will  be  a  scalable  solution  able  to  manage  fuel  on  an 
individual  ship,  a  destroyer  squadron,  carrier  strike  group  or  at  the  numbered  fleet  level. 
The  system  will  provide  not  only  point-to-point  optimal  solutions,  but  also  will  allow  the 
fueling  plans  to  encompass  all  operations.  It  can  be  modified  whenever  operational 
factors  dictate  deviations.  Operational  boxes  (OPBOX)  will  be  included  in  the  solution 
where  different  levels  of  operations  can  be  selected  to  account  for  varying  fuel  usage 
during  operations. 

The  goal  of  the  system  is  to  allow  decision  makers  to  plan  more  efficient  and 
economic  usage  of  the  limited  resource  of  fuel  onboard  Navy  ships.  The  Naval  Fuel 
Management  System  will  be  a  DSS  tool  in  which  a  fuel  plan  can  be  created,  allowing 
ships  more  time  on  station,  minimizing  periodic  scheduled  refueling,  and  needless  brief 
stops  for  fuel  (BSF). 
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I.  INTRODUCTION 


A.  BACKGROUND 

Today’s  ships  are  limited  in  time  on  station  based  upon  how  much  fuel  they  burn 
at  sea.  Awards  are  given  to  units  who  use  the  least  fuel  or  are  fuel  conservative  in  their 
operations.  However,  little  is  done  to  manage  and  plan  for  fuel  usage  during  training 
exercises  and  operational  deployments  alike.  Tracking  fuel  usage  from  antiquated 
systems  or  on  paper  has  become  the  norm  and  has  created  a  reactionary  disposition  to 
refueling  operations.  Rather  than  planning  and  optimizing  refueling  points,  refueling  is 
either  scheduled  on  a  periodic  basis,  or  arrangements  are  made  one  to  two  weeks  in 
advance,  giving  little  notice  to  the  ports  or  ships  that  provide  fuel. 

A  system  can  be  developed  that  accurately  predicts  fueling  requirements  for  a 
specified  period  of  time,  over  either  an  operational  or  training  deployment,  to  determine 
an  optimized  fuel  path.  The  result  is  more  time  on  station,  less  costs  associated  with 
refueling,  and  perhaps  fewer  ships  required  to  maintain  24/7  operations. 

B.  PROBLEM 

Current  practices  to  determine  fueling  points  use  paper  calculations  in  the  form  of 
bum  charts,  and  an  oversimplified  model,  the  Position  of  Intended  Movement  (PIM),  as 
input  variables.  The  PIM  model  is  oversimplified  because  it  takes  into  account  only  a 
ship’s  course  and  speed;  there  is  no  offset  for  winds,  tides  or  currents  affecting  how  the 
ship  actually  moves  through  the  water.  Fueling  arrangements  are  made  either  on  a 
periodic  basis  or,  at  most,  one  or  two  weeks  before  the  intended  refueling  date.  The 
periodic  refueling  schedule  wastes  fuel  both  in  reaching  the  refueling  points,  and 
steaming  on  all  main  engines  during  the  refueling  process,  not  to  mention  the  incursion  of 
port  fees  for  brief  stops  for  fuel  (BSF).  In  addition,  needlessly  refueling  removes  an  asset 
from  station  for  the  time  required  for  refueling.  The  periodic  schedule  wastes  man  hours 
and  can  add  stress  to  a  crew  already  dealing  with  high- tempo  operations  in  today’s  naval 
environment. 
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The  Naval  Fuel  Management  System  (NFMS)  will  address  these  problems  by 
providing  a  Decision  Support  System  (DSS)  that  integrates  diverse  data  sources, 
generates  and  solves  an  optimization  model,  and  provides  various  data  visualization 
interfaces  that  can  in  principle  be  deployed  on  several  different  technology  platforms. 
The  NFMS  will  allow  decision  makers  and  stakeholders  to  develop  a  fueling  plan  prior  to 
a  ship  leaving  the  pier.  This  will  allow  a  model  to  be  generated  to  optimize  which 
refueling  points  to  use.  If  the  weather  or  the  destination  or  operational  route  changes  as 
the  plan  progresses,  decision  makers  can  dynamically  rerun  the  optimization  model  with 
new  input  variables  providing  an  updated  optimum  plan.  Thus,  the  refueling  plan  process 
gains  a  significant  degree  of  flexibility  over  the  current  static  methodology. 

The  methodology  of  this  thesis  is  to  first  define  the  requirements  for  the  NFMS, 
outlining  which  systems  are  currently  available  and  which  need  to  be  acquired.  Next  a 
basic  design  of  the  NFMS  will  be  developed  using  infonnation  flows.  A  proof  of  concept 
will  be  used  describing  where  the  calculations  are  made  and  how  the  system  will  define 
an  optimized  route  based  on  the  amount  fuel  burned  for  the  overall  fuel  plan.  Finally, 
some  mock-ups  of  screen  shots  will  be  included  to  demonstrate  they  type  of  intuitive  map 
based  GUI,  which  should  be  utilized  for  this  type  of  application. 

C.  SCOPE  OF  THE  THESIS 

The  scope  of  this  thesis  is  limited  to  requirements  gathering  and  a  basic  system 
design.  Because  other  UNCLASS  and  SECRET  working  systems  are  required  to 
implement  even  a  prototype  system,  full  implementation  will  not  be  possible.  A  working 
Microsoft  Excel™  shortest  path  transportation  network  analysis  linear  program  will  be 
designed  around  a  single  ship  scenario  for  a  proof  of  concept  as  the  decision  support 
engine  for  the  system.  Use-cases  and  storyboards  will  be  used  to  demonstrate  the 
functionality  of  the  proposed  DSS. 

D.  ORGANIZATION 

The  remainder  of  this  thesis  is  separated  into  six  chapters.  Chapter  II  will 

describe  and  define  the  requirements  for  the  NFMS.  Chapter  III  describes  the  design  for 

NFMS  including  services,  data  structures,  and  information  flows.  Chapter  IV 
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demonstrates  the  shortest  path  transportation  network  analysis  proof  of  concept  and 
Chapter  V  describes  the  user  interfaces.  Chapter  VI  is  the  concluding  chapter 
summarizing  recommendations  and  future  work. 
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II.  NFMS  DESIGN  REQUIREMENTS 


A.  DECISION  PARAMETERS 

When  designing  a  decision  support  system,  it  is  necessary  to  consider  the  decision 
parameters  that  constrain  the  decision-making  process.  These  parameters  can  be  fleshed 
out  by  addressing  a  few  key  questions. 

1.  Who  Are  the  Decision  Makers  and  Stakeholders? 

One  way  of  identifying  the  NFMS  decision  makers  and  stakeholders  is  to  work 
from  lower  unit  levels  up  the  chain  of  command  (COC)  within  the  Navy. 

At  the  unit  or  ship  level,  the  Commanding  Officer  (CO)  is  the  key  decision  maker 
onboard.  The  CO  ultimately  decides  where  the  ship  will  refuel  and  how  often. 
Stakeholders  onboard  also  include  the  Fuels  Officer  and/or  the  Chief  Engineer  who  track 
fuel  percentages  onboard  and  report  to  the  CO.  The  Operations  Officer  schedules  the 
fuel  stops  and  is  also  a  key  stakeholder  in  the  decision-making  process  of  fuel  planning. 

At  the  Group  level,  whether  it  is  a  smaller  Destroyer  Squadron  (DESRON),  or  a 
larger  Carrier  Strike  Group  (CSG),  the  key  decision  maker  is  the  Commodore.  He  is 
supported  by  the  Operations  Officer  in  the  N3  code,  and  the  Supply  Officer  in  the  N7 
code,  to  arrange  for  Group  level  fuel  planning.  A  larger  group  would  normally  have  a 
refueling  asset,  in  the  form  of  an  oiler  to  assist  in  sustaining  operations,  rendering  this 
decision-making  environment  even  more  complex. 

At  the  Fleet  or  Combatant  Command  level,  the  key  decision  makers  are  the  Fleet 
Commanders  or  Combatant  Commanders.  These  decision  makers  are  looking  at  a  much 
larger  abstraction  of  groups  of  ships  and  how  they  are  moving  and  refueling  in  a  specific 
area  of  operations  (AOR).  The  Fleet  and  Combatant  Commanders  will  have  refueling 
assets  and  ports  assigned  to  them,  as  well  as  several  oilers. 
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2. 


What  Are  the  Decisions  That  Need  to  Be  Made? 


The  key  decision  that  needs  to  be  made  in  the  refueling  environment  is  as  follows: 

•  When  and  where  should  my/each  ship  refuel  for  an  optimal  route — a  route 
that  uses  the  least  amount  of  fuel,  but  still  allows  for  making  the  scheduled 
fixed  ports  on  time? 

3.  What  is  the  Time  Window  that  Decisions  Have  to  be  Made? 

The  Navy  needs  to  submit  estimates  of  how  much  fuel  it  expects  to  use  in  any 
given  fiscal  year.  If  deployments  and  training  exercises  can  be  scheduled  two  years  out, 
the  NFMS  can  be  used  to  create  these  fuel  consumption  estimates  for  the  Navy  as  a 
whole.  However,  assuming  that  weather  patterns  and  deployment  schedules  will  not 
change  over  a  two-year  period  is  entirely  unrealistic.  Therefore,  once  a  deployment  or 
exercise  timeline  is  mapped  out  by  the  Operations  Officer  at  the  Fleet,  Group,  or  Unit 
level,  then  the  refueling  locations  will  immediately  come  into  question.  Typically,  this 
can  be  as  early  as  six  months  but  typically  no  later  than  three  months  from  when  the  ship 
is  scheduled  to  leave  the  pier. 

Since  the  weather  predictions  can  change  every  12  hours,  then  the  optimal  route 
can  potentially  change  every  12  hours  as  well.  This  would  be  too  volatile  a  timeframe  to 
commit  to  any  sort  of  a  refueling  plan.  Also,  it  typically  takes  36-48  hours  to  schedule  a 
port  call,  even  for  a  brief  stop  for  fuel  (BSF).  Therefore,  the  decision  to  change  a 
refueling  port  must  occur  within  36  hours  of  going  into  that  port. 

4.  What  is  the  Cost  or  Assumed  Risk  of  a  Poor  Decision? 

The  highest  possible  risk  would  be  a  Navy  vessel  running  out  of  fuel  and  needing 
to  be  towed  into  port.  The  cost  would  not  only  be  tangible  in  the  form  of  extra  services 
for  the  towing  tugs,  but  also  intangible  in  the  form  of  damage  to  the  reputation  of  the 
Navy  as  a  whole  within  the  international  sailing  community. 

A  more  likely  risk  is  the  cost  accrued  in  wasted  time  and  fuel  for  needless 
refueling.  The  tradeoff,  therefore,  is  between  running  out  of  fuel  and  incurring  the 
expense  of  refueling  needlessly.  However,  on  12  October  2000,  the  largest  and 

unexpected  cost  of  a  poor  refueling  decision  was  realized  when  the  USS  Cole  was 
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attacked  in  the  Port  of  Aden.  The  USS  Cole  underestimated  its  fuel  consumption  going 
through  the  Suez  Canal  and  needed  to  refuel.  An  impromptu  BSF  was  called  for  the  Port 
of  Aden,  and  the  terrorists  took  the  opportunity  to  attack.  Now  it  is  standard  operating 
procedure  (SOP)  that  a  security  team  does  a  sweep  and  risk  assessment  of  any  overseas 
port  prior  to  a  ship  entering.  The  need  for  a  security  team  to  sweep  a  pier  prior  to 
refueling  adds  to  the  cost  each  time  a  ship  pulls  in  to  refuel.  Therefore,  these  should  not 
be  wasteful,  periodic  or  unnecessary  stops,  but  rather,  well  thought  out  and  optimal 
decisions  for  a  refueling  plan. 

NFMS  does  not  inherently  lower  the  risk  involved  with  operating  at  lower  than 
comfortable  fuel  percentages.  However,  it  gives  Commanders  at  all  levels  a  tool  to  plan 
and  make  decisions.  By  tying  weather  as  part  of  the  model,  NFMS  mitigates  the  risk  of 
using  unreliable  inaccurate  estimating  techniques  such  as  the  PIM  model.  Therefore, 
Commanders  will  be  more  likely  to  take  on  more  risk  by  allowing  fuel  percentages  to 
drop  lower  than  they  were  comfortable  before  having  a  DSS  such  as  NFMS.  Currently, 
without  a  DSS,  Commanders  mitigate  the  risk  of  running  out  of  fuel  by  periodically 
refueling,  a  wasteful,  simplistic  and  inefficient  solution.  NFMS  gives  the  Commanders 
an  alternate  way  to  mitigate  the  risk  by  planning  ahead  of  time  with  an  accurate, 
optimized  model. 

5.  Where  do  Risks  and  Uncertainties  Lie  in  the  Decision  Process? 

Weather  and  actual-versus-predicted  fuel  consumption  provide  the  biggest 
uncertainty  in  the  fuel-planning  decision  process.  Also,  as  noted  in  the  assumptions, 
ships  often  do  not  travel  in  a  straight  line,  just  going  directly  from  port  A  to  port  B.  Ships 
may  perform  various  operations,  such  as  practicing  high-speed  drills  and  maneuvers,  or 
conducting  divisional  tactics  (DIVTACS)  exercises,  or  they  may  need  to  “drive  for  wind” 
in  flight  operations.  All  of  these  different  maneuvers  add  complexity  and  uncertainty  to 
the  fuel  planning  decision  process. 

Because  the  fuel  planning  process  is  so  difficult,  U.S.  ships  refuel  too  often  and 
waste  time  and  resources  needlessly  refueling.  If  the  complexity  can  be  reduced  by  using 
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a  DSS  such  as  NFMS,  then  large  amounts  of  resources  can  potentially  be  saved,  with 
ships  spending  more  time  on  station  and  less  time  refueling  or  traveling  to  refuel. 


B.  NETWORK  REQUIREMENTS 

1.  Service-Oriented  Architecture  (SOA) 

As  the  Navy  and  the  Department  of  Defense  (DoD)  transition  to  a  net-centric 
environment,  several  documents  drive  new  system  acquisitions  from  stove-piped 
standalone  systems  to  a  service-oriented  architecture  (SOA)  approach.  Legacy  stove- 
piped  systems  cause  information  to  be  hoarded  rather  than  shared,  which  effectively 
blocks  the  proposed  functionality  of  a  system  like  NFMS.  It  is  equivalent  to  tracking 
refueling  locations  and  available  assets  on  Excel™  spreadsheets  or  in-house  databases,  a 
practice  still  too  common  today.  This  old  methodology  of  using  information  technology 
(IT)  is  inefficient  and  makes  duplication  of  effort  nearly  unavoidable.  The  Global 
Information  Grid  (GIG)  Architectural  Vision  [1]  circumvents  the  hoarding  of  information 
by  mandating  the  use  of  SOA  that  emphasizes  the  sharing  of  infonnation  through 
services.  The  GIG  provides  the  vehicle  to  reduce  duplication  of  effort,  providing  the  kind 
of  Net-Centrality  needed  to  solve  the  refueling  problem  above.  SOA  as  a  requirement 
increases  the  reusability  of  systems  and  applications,  which  in  turn,  frees  budget 
resources  for  developing  useful  new  information  systems  and  applications.  The  DoD 
Defense  Infonnation  Enterprise  Architecture  [2]  subsequently  formalizes  what  is  needed 
to  have  a  secure  SOA  to  support  the  GIG  Architectural  Vision.  These  documents  are 
cited  in  the  Defense  Acquisitions  Guide  (DAG)  [3],  which  requires  that  any  IT 
acquisition  must  adhere  to  this  model. 

2.  Valued  Information  at  the  Right  Time  (VIRT) 

VIRT  is  a  philosophy  of  how  to  build  communication  flows  in  order  to  achieve 

the  highest  efficiency  within  the  bandwidth  made  available  for  any  information  system. 

This  can  be  a  difficult  task  in  today’s  networked  environment  where  systems  of  systems 

are  constantly  communicating.  These  communications  often  contain  superfluous 

information,  resulting  in  a  low  signal-to-noise  ratio  (SNR).  VIRT  suggests  that  the  most 

efficient  way  to  share  information  is  to  first  define  an  ontology,  or  standard  framework  of 
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vocabulary  for  the  application  domain,  and  then  identify  the  infonnation  of  value,  and 
when  it  is  relevant  to  send  [4].  An  example  of  VIRT  is  a  traffic  stop  light  camera.  It 
monitors  an  intersection  on  a  24/7  basis;  however,  no  data  is  transmitted  until  a  car  runs  a 
red  light. 

SO  A  and  VIRT  by  their  nature  have  conflicting  objectives  when  it  comes  to 
bandwidth  consumption.  The  end  user  of  NFMS  will  be  operating  on  ships,  where  the 
only  source  of  connectivity  is  often  through  SHF  satellite  communications.  This  makes 
bandwidth  a  valuable  and  constrained  resource.  Any  information  sent  across  the  satellite 
network  should  be  valuable.  The  DoD  requirement  of  a  SOA  approach  to  solving 
problems  with  IT  can  be  seen  as  in  direct  conflict  with  operating  in  a  constrained 
bandwidth  environment.  SOA  can  be  noisy,  requiring  many  function  calls  across 
networks  to  solve  a  problem.  Valuable  infonnation  is  defined  as  being  timely,  relevant, 
and  concise.  By  applying  the  principles  of  VIRT,  the  valuable  information  can  be 
identified.  A  condition  monitor  can  be  used  and  the  limited  bandwidth  can  be  utilized 
only  when  the  condition  monitor  detects  that  information  needs  to  be  sent  to  the  ship. 
VIRT  is  an  ideal  solution  to  the  problem  of  using  a  SOA  approach  in  a  constrained 
bandwidth  environment  and  is  recommend  as  part  of  the  NFMS  solution. 

C.  MODELS 

NFMS  is  essentially  both  a  data-driven  and  model-driven  DSS  [5].  The  models 
essentially  drive  the  data  requirements,  so  we  will  discuss  them  first. 

1,  Route  Generator  Model 

The  simplistic  PIM  model  to  predict  fuel  percentages  is  not  robust  enough  to 
provide  a  level  of  confidence  sufficient  to  predict  fuel  usage  accurately  and  to  serve  as 
the  basis  for  an  optimal  fuel  plan.  Therefore,  a  route  generator  model  is  needed  that  takes 
into  account  the  currents,  tides,  and  winds  of  the  sea.  If  a  ship  hits  heavy  weather,  then 
more  fuel  will  be  expended  to  go  through  the  stonn.  Also,  if  the  winds  and  seas  are 
“following,”  then  the  ship  will  use  less  fuel  than  predicted  by  the  PIM  model.  Weather 
can  be  unpredictable  and  must  be  monitored  constantly  to  ensure  significant  changes  are 
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applied  to  the  route.  Therefore  the  route  generator  should  be  able  to  provide  a  closer 
prediction  to  the  actual  courses  and  speeds  needed  to  get  to  each  fixed  port  on  time,  using 
weather  as  an  offset  to  PIM  course  and  speed. 

2.  Refueling  Optimization  Model 

In  operations  research,  a  linear  program  can  be  used  to  solve  a  shortest  path 
transportation  network  problem,  identifying  the  shortest  path  for  a  vehicle  to  take  within 
the  transportation  network.  This  well-known  analysis  is  based  upon  weighted  links.  The 
transportation  network  model  is  at  the  heart  of  the  NFMS,  providing  the  necessary 
computational  engine  to  identify  the  optimal  route. 

D.  DATA 

Since  NFMS  is  both  a  model  and  data  driven  DSS,  there  are  significant  data 
integration  requirements  in  order  to  instantiate,  and  ultimately  solve,  any  particular 
model. 


1.  Fuel  Schedule  Management 

The  NFMS  will  need  a  fuel  schedule  management  system  that  enumerates  which 
days  of  the  year  oilers  and  ports  are  available  for  refueling.  Port  availability  can  be 
tracked  simply  by  date  time  groups;  oiler  data,  however,  is  multi-dimensional.  An  oiler 
can  be  available  at  different  locations  throughout  the  oceans  at  different  times,  and  its 
schedule  can  change  frequently.  Therefore,  a  service  is  needed  that  makes  the  oiler 
schedule  data  available  in  a  format  NFMS  can  interpret. 

The  scope  of  this  thesis  is  not  to  define  the  requirements  for  the  supporting 
systems  feeding  the  NFMS,  but  rather  to  identify  the  requirements  and  suggest  a  design 
for  the  NFMS  itself.  A  Fuel  Schedule  Management  system  is  one  of  the  required 
supporting  services  needed  for  the  NFMS. 
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2. 


Weather  Data 


Weather  data  needs  to  be  available  consistently  to  the  NFMS  and  provide  periodic 
updates  of  the  weather  along  route  of  the  fuel  plan.  Variations  in  the  weather  can  cause 
cascading  changes  ultimately  affecting  the  optimal  fuel  plan;  therefore,  an  early  rather 
than  later  realization  of  weather  changes  is  a  critical  success  factor  for  NFMS.  Also,  it  is 
necessary  to  recall  that  a  36-  to  48-hour  notice  is  normally  required  to  change  rendezvous 
arrangements  with  oilers  as  well  as  port  calls  for  refueling. 

3.  Transportation  Network  Generation  Data 

Once  potential  fueling  points  are  identified  by  the  fuel  scheduling  system  and  the 
weather  is  applied  to  routes,  transportation  network  data  can  be  created  by  the  NFMS. 
This  data  includes  the  waypoints  of  a  particular  route.  A  waypoint  may  be  a  port,  an  oiler 
rendezvous  or  just  a  turn  in  the  sea.  Waypoints  will  be  defined  by  date  time  groups  and 
will  also  have  the  actual  courses  and  speeds  associated  with  them.  If  a  beginning  fuel 
percentage  is  known,  then  each  waypoint  may  have  an  associated  fuel  percentage, 
ultimately  predicting  the  use  of  fuel  along  the  route. 

E.  USER  INTERFACES 

1.  Input 

Input  to  the  NFMS  should  be  mostly  automated,  straightforward  text-based  data. 
Latitude  and  longitude  should  be  available  to  set  waypoints  as  well  as  selecting  port 
names  and  oilers  for  reuse  of  information  throughout  the  system.  Ports  and  Oilers  should 
be  set  as  fixed/hard  unchangeable  stops,  or  else  they  will  be  considered  soft  points  that 
can  be  omitted  or  the  times  of  refueling  can  change  to  reveal  an  optimal  plan. 

The  user  should  be  also  be  able  to  input  daily  updated  fuel  percentages  to  track  if 
the  ship  is  maintaining  the  optimal  plan  within  sensitivity  limits. 
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2. 


Visualization 


NFMS  should  use  a  map  based  graphical  user  interface  (GUI)  to  show  the  optimal 
route.  Also,  a  summary  report  of  speed  changes  and  fuel  percentages  along  the  route 
should  be  made  available  to  the  user  for  self  tracking. 

NFMS  will  solve  the  complex  problem  of  when  to  refuel  Navy  ships.  This  will 
allow  Commanders  to  feel  comfortable  taking  on  more  risk  by  going  lower  on  the  reserve 
stock  of  fuel  onboard.  The  trade-off  is  a  more  efficient  use  of  fuel  and  a  cost  savings  to 
the  Navy.  Requirements  to  solve  such  a  complex  problem  include  services  for  weather 
and  route  generation,  as  well  as  models  to  ensure  the  most  efficient  path  is  taken,  which 
still  allows  ships  to  make  their  port  of  call  on  time.  Also,  the  interface  should  be 
straightforward  and  intuitive.  Next  will  be  an  initial  design  that  uses  some  existing 
services  currently  available  for  such  an  application  and  identifies  other  valuable  systems 
the  Navy  should  invest  in  to  make  NFMS  DSS  operational. 
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III.  SERVICES,  DATA  STRUCTURES  AND  INFORMATION 

FLOW  DESIGN 

A.  PROPOSED  NETWORK  TOPOLOGY  DESIGN 

By  applying  the  philosophy  of  VIRT  to  SOA,  it  becomes  obvious  that  most  of  the 
processing  will  need  to  take  place  on  shore  where  bandwidth  is  more  readily  available, 
and  the  messages  from  ship  to  shore  made  as  efficient  as  possible.  The  proposed  network 
topology  design  for  NFMS  reflects  this  constraint,  as  shown  in  Figure  1.  There  are  two 
major  components  to  the  NFMS:  A  ship  component  where  the  user  will  interface  with 
the  system,  providing  inputs  and  requesting  and  maintaining  fuel  plans,  and  a  shore  side 
component  where  the  server  will  receive  the  variables,  requests,  and  updates  to  the  fuel 
plan,  interact  with  the  route  generator  and  the  Fuel  Schedule  Management  Database 
(FSMD),  and  return  an  optimized  fuel  plan.  A  route  generator  service  is  currently 
available  from  Fleet  Numerical  Meteorology  and  Oceanographic  Center  (FNMOC),  so 
FNMOC  will  need  to  be  a  node  in  the  network  topology.  Additionally,  NFMS  requires  a 
Fuel  Schedule  Management  Database  that  will  need  to  be  developed  as  a  service  for  the 
fleet.  A  node  containing  the  FSMD  server  will  also  be  part  of  the  NFMS  network 
topology.  The  NFMS  CONUS  server  will  also  act  as  a  condition  monitor  from  the  VIRT 
philosophy  to  alert  the  ship  when  the  plan  has  changed,  either  due  to  weather  changes 
(provided  from  FNMOC)  or  the  availability  of  better  refueling  options  (provided  from  the 
FSMD). 
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Figure  1 .  NFMS  High  Level  Diagram 


B.  AUTOMATED  OPTIMUM  SHIP  TRACK  ROUTE 

NFMS  will  use  an  existing  IT  application  provided  by  FNMOC  called  Automated 
Optimum  Ship  Track  Route  (AOTSR)  that  will  provide  the  route  generator  service  [6]. 
Detailed  descriptions  of  data  input  and  output  formats  will  be  discussed  later  in  this 
chapter.  The  AOTSR  works  over  the  Web  using  XML  for  its  input  and  output  interface. 
The  service  takes  as  input  a  series  of  waypoints  with  associated  date  time  groups  (DTGs), 
and  returns  an  optimum  track  set  of  waypoints,  based  on  weather  predictions  in  that  area. 
AOTSR  uses  historical  climate  data  to  produce  its  tracks  for  long  term  planning.  For 
short  term  planning,  AOTSR  uses  the  current  forecast  available  in  the  AOR.  It  returns 
actual  course  and  speeds  required  to  reach  the  waypoints  on  time.  By  using  the  AOTSR, 
the  current  oversimplified  calculation  detennining  the  PIM  track  is  replaced  by  estimated 
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actual  courses  and  speeds  to  get  to  each  waypoint  on  time.  This  will  provide  a  better 
estimate  of  fuel  consumption,  rendering  NFMS  a  more  reliable  and  accurate  DSS  in  the 
process. 

C.  FUEL  SCHEDULE  MANAGEMENT  DATABASE 

NFMS  will  also  require  a  database  of  current  and  future  refueling  points  available 
as  another  service.  Current  refueling  operations  occur  on  either  a  periodic  or  ad-hoc 
basis,  and  are  tracked  manually.  The  only  records  of  set  refueling  plans  are  naval 
messages  sent  between  ships  making  arrangements.  There  is  no  set  database  to  track 
current  and  future  refueling  operations.  There  are  two  ways  Navy  ships  receive  fuel: 
either  by  refueling  at  sea  (RAS),  or  pulling  into  port  for  a  brief  stop  for  fuel  (BSF).  BSFs 
are  often  combined  with  liberty  ports  where  ships  stay  for  a  longer  period  of  time.  A 
proposed  FSMD  will  be  recommended  as  part  of  NFMS.  This  database,  in  addition  to 
providing  a  critical  service  required  for  NFMS,  could  also  serve  as  a  central  repository 
for  de-conflicting  fueling  operations  throughout  the  Navy.  It  would  be  able  to  answer  the 
following  questions: 

•  Which  ports  are  open  for  refueling  and  when? 

•  Will  my  ship’s  draft  allow  me  to  use  this  port  for  refueling? 

•  What  are  the  RAS  rendezvous  on  a  particular  day  /  time  with  a  fleet  oiler? 

•  What  are  the  current  positions  and  future  movements  of  the  fleet  oilers? 

Creating  a  database  of  refueling  information  would  fit  naturally  into  the  SOA 
paradigm.  This  thesis  sketches  a  few  preliminary  ideas  for  the  structure  and  usage  of  an 
FSMD  but  leaves  the  full  development  of  such  a  database  to  future  research  efforts. 

D.  TRIGGERS  THAT  CHANGE  THE  FUEL  PLAN 

Once  an  optimized  plan  is  created  and  the  ship  is  committed  to  it,  the  three 
CONUS  servers  will  work  to  ensure  the  route  remains  optimum  or  near  optimum.  There 
are  several  conditions  that  would  require  the  route  to  be  altered.  In  each  of  these 
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scenarios,  changes  of  state  in  the  fuel  plan  should  automatically  prompt  the  ship  that  its 
fuel  plan  has  changed  without  the  need  for  manual  user  input. 

1 .  Since  weather  forecasts  are  published  to  AOTSR  twice  a  day,  a  new  weather 
pattern  may  alter  the  weights  of  the  links  sufficiently  to  require  a  change  in  route. 

2.  If  a  scheduled  refueling  point  changes  its  state  (e.g.,  a  fleet  oiler  does  not  sail, 
or  there  is  a  port  closure),  then  that  node  will  be  removed  from  the  transportation 
network  necessitating  a  change  in  the  route. 

3.  If  a  new  refueling  point  becomes  available  for  possible  scheduling,  it  may 
potentially  provide  a  more  efficient  path  to  take. 

For  these  three  scenarios,  a  periodicity  of  24  hours  should  be  used  to  check  the 
plan  for  optimal  efficiency.  This  24-hour  cycle  will  take  into  account  any  new  weather 
predictions  and  the  updating  of  fueling  points  in  the  database.  If  the  optimized  plan 
remains  unchanged  then  a  “heartbeat”  can  be  sent  to  the  ship  indicating  no  change.  If  the 
optimized  path  has  changed,  the  new  computed  route  should  be  sent. 

There  are  several  conditions  which,  if  triggered  from  the  ship  side,  could  also 
result  in  changes  to  the  optimum  plan: 

1.  If  the  current  fuel  percentage  does  not  match  the  planned  fuel  percentage, 
within  sensitivity. 

2.  If  the  fixed/unchangeable  waypoints  for  the  ship  change  due  to  ship  schedule 
changes. 

3.  If  the  endpoint  changes  due  to  ship  schedule  changes. 

Each  of  these  scenarios  would  require  updated  input  variables  to  the  NFMS, 
which  could  then  recompute  the  optimization  analysis  on  current  weather  and  refueling 
points  to  return  an  optimal  path. 

In  summary,  the  proposed  network  topology  in  Figure  1  describes  three  systems 

in  CONUS  working  in  synch  to  provide  information  to  the  ship  connected  wirelessly  via 

satellite.  The  ship-shore  satellite  communications  are  where  the  VIRT  principle  needs  to 

be  assiduously  applied.  What  the  ship  requires  from  the  NFMS  CONUS  server  is  the 
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current  optimized  fuel  plan,  as  well  as  any  triggers,  or  alerts  that  can  potentially  affect  the 
current  plan.  What  the  CONUS  server  requires  form  the  ship  in  order  to  calculate  a  fuel 
plan  is  ship  location,  expected  fuel  percentage  at  the  start  of  the  plan,  destination 
location(s),  fixed  expected  stops,  and  refueling  activities  at  those  stops,  if  any.  After 
these  variables  are  provided  to  the  NFMS  CONUS  server,  it  can  subsequently  request  the 
requisite  large  quantities  of  information  from  the  AOTSR  and  the  FSMD  without 
compromising  the  limited  ship-to-shore  satellite  bandwidth  capacity. 

E.  INFORMATION  FLOW  DESIGN 

Now  that  the  high-level  network  topology  for  NFMS  has  been  specified,  and  the 
change  scenarios  enumerated,  the  next  step  is  to  define  the  information  flows  amongst  the 
systems,  including  the  data  schema  required  for  each  scenario.  The  following 
information  flows  are  provided  in  detail  to  show  how  the  services  will  interact  to  generate 
and  maintain  the  optimal  fuel  plan. 

The  first  information  flow  documents  the  most  basic  process,  the  initial  plan 
creation.  The  initial  solution  of  the  optimization  model  becomes  the  baseline  plan  from 
which  subsequent  update  operations  are  performed  if  and  when  necessary. 

1.  Initial  Plan  Creation 

a.  Input  to  CONUS 

Generation  of  an  initial  plan  will  be  initiated  by  an  input  from  the  ship  side 
systems.  A  user  will  first  select  a  new  plan  that  the  server  will  assign  a  unique  identifier 
to  ensure  that  the  most  current  plan  is  always  utilized.  Since  the  planning  inputs  will  be 
sent  to  the  CONUS  server,  the  plan  identifier  should  be  unique  to  each  ship.  The 
recommended  numbering  schema  is  SSSSSppppvv  where 

SSSSS  ship  ID 

pppp  plan  # 

vv  version  #  of  the  plan 

Ex:  DDG69000101  refers  to  Ship  DDG69,  Plan  0001,  Version  01. 
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The  ship  server  will  need  some  initial  variable  inputs  from  the  user  to 
begin  the  planning  process.  These  will  be  provided  as  a  series  of  waypoints.  The 
waypoints  will  be  predefined  in  the  server  as  the  most  common  stops  that  U.S.  Naval 
vessels  use,  for  example  Norfolk,  VA,  San  Diego,  CA,  Mayport  FL,  Everett,  WA,  and 
many  overseas  ports  such  as  Bahrain,  Dubai,  Mallorca  Spain,  Rota,  Malta,  and  Djibouti . 
The  ports  will  also  require  associated  date  time  groups  (DTG).  The  initial  beginning 
waypoint  will  only  require  a  departing  DTG  whereas  the  ending  waypoint  (n)  will  only 
require  an  arrival  DTG.  All  waypoints  in  between  will  require  both  an  arrival  and 
departure  DTG.  All  DTG  should  be  kept  in  Zulu,  which  will  minimize  the  need  to  adjust 
for  time  zones  and  avoid  any  errors  associated  with  such  calculations.  Each  waypoint 
entered  by  the  user  for  initial  plan  creation  should  be  a  hard,  fixed  stop  since  the  intent  is 
for  NFMS  to  find  the  optimum  refueling  points  along  a  fixed  track.  For  example,  if  it  is 
more  fuel  efficient  to  pull  in  for  a  three-day  liberty  port,  then  RAS  the  next  day,  the 
system  will  return  that  track. 

The  user  will  next  enter  the  beginning  fuel  percentage  for  the  voyage  plan. 
The  system  should  default  to  approx  90%,  as  most  ships  are  not  always  at  100%  when 
beginning  a  voyage.  Finally,  the  user  should  enter  the  required  refueling  percentage  for 
pulling  into  port  on  its  final  stop.  The  default  should  be  set  around  80%,  as  this  is  the 
most  common  requirement. 

If  the  ports  are  known  to  the  system,  then  there  is  no  need  to  send  the 
latitude  and  longitude  as  well.  This  would  be  sending  extraneous,  repetitive  information 
in  violation  of  the  VIRT  philosophy.  Adding  a  new  port  to  the  system  is  a  special  use- 
case  that  will  be  defined  in  the  use-case  section.  The  database  of  known  ports  should  be 
synchronized  across  all  the  ships  and  the  CONUS  server;  therefore,  only  a  unique 
identifier  will  need  to  be  passed  for  each  waypoint.  The  example  input  in  Table  1  does 
not  show  the  port  name,  all  NFMS  will  have  an  updated  repository  of  port  names  as 
shown  in  Table  2.  This  way  only  the  port  name  identifier  number  will  be  transmitted, 
minimizing  the  size  of  each  transition,  and  allowing  for  standardization  of  well-known 
and  used  ports. 
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A  summary  of  input  variables  from  the  ship  server  to  NFMS  CONUS 
server  for  an  initial  fuel  plan  is  as  follows: 


Type 

ID 

Waypoint 

# 

Port 

ID 

Arrive 

Depart 

Percentage 

Given/Required 

1 

DDG69000101 

1 

569 

N/A  Begin  Plan 

01-Jan-201 1, 
0830z 

83% 

1 

DDG69000101 

2 

801 

08- Jan-20 11, 
lOOOz 

1  l-Jan-201 1, 
1200z 

1 

DDG69000101 

3 

203 

16- Jan-20 11, 
0900z 

18-Jan-201 1, 
1200z 

1 

DDG69000101 

4 

506 

05-Feb-2011, 

1215z 

12-Feb-2011, 

1300z 

1 

DDG69000101 

5 

538 

28-Feb-2011, 

1500z 

08-Mar-201 1, 
lOOOz 

1 

DDG69000101 

6 

301 

15-Mar-201 1, 
0800z 

19-Mar-201 1, 
1045z 

1 

DDG69000101 

7 

569 

31 -Mar-2011, 
0800z 

N/A  End  Plan 

85% 

Table  1.  Summary  of  input  from  ship  to  NFMS  CONUS  server 


The  location  of  the  port  can  be  found  by  using  the  table  of  common  ports, 
which  should  be  located  and  updated  on  the  NFMS  CONUS  server,  and  replicated  on 
each  ship  server.  Table  2  represents  a  small  excerpt  of  the  table  for  this  example. 


NFMS  CONUS  Server  Table  of  Port  Names  and  Locations 

ID 

Port  Name 

Latitude 

Longitude 

569 

Norfolk,  VA 

36°59’33”N 

76°20’32”W 

801 

Rota  Spain 

36°34’59”N 

6°20’35”W 

203 

Malta 

35°48’48”N 

14°25’51”E 

506 

Dubai 

25°17’22”N 

55°16’13”E 

538 

Mallorca  Spain 

39°19’45”N 

2°55’14”E 

301 

Portsmouth  England 

50°47’20”N 

1°06’36”W 

569 

Norfolk,  VA 

36°59’33”N 

76°20’32”W 

Table  2.  Excerpt  of  NFMS  CONUS  Server  table  of  port  names  and  locations. 
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The  NFMS  will  also  need  to  know  the  different  types  of  tables  and 
message  schemas  available.  Table  3  represents  an  excerpt  of  this  table  for  this  example. 


NFMS  Message  Types 

Type  ID 

Name 

1 

Request  New  Plan 

2 

Return  Fuel  Points 

3 

Optimized  Plan  Result 

4 

Optimized  Plan  Update 

5 

Optimized  Plan  Replace 

6 

Current  Fuel  Percentage  Update 

Table  3.  Excerpt  of  NFMS  table  of  message  and  or  table  types. 

b.  Request  Fuel  Points 

Once  the  NFMS  CONUS  server  has  the  full  set  of  required  input 
variables,  it  can  request,  via  a  function  call,  fueling  points  along  the  voyage  from  the 
FSMD.  The  return  data  will  be  a  series  of  potential  refueling  points  a  ship  can  use  along 
its  voyage  plan.  A  limit  to  the  distance  from  the  initial  track  alternate  points  will  be 
searched  for  can  be  defined  as  the  mean  speed  of  ship  multiplied  by  the  time  it  takes  to 
reach  exhaustion  of  fuel.  This  will  be  different  for  each  ship  class,  and  will  yield  a  large, 
but  limited,  number  of  alternate  refueling  points  along  a  track.  In  addition,  when  a  fleet 
oiler  is  a  potential  stop,  the  optimal  RAS  rendezvous  location  will  be  revealed  in  the 
analysis  as  well.  Data  returned  from  the  FSMD  to  the  NFMS  CONUS  server  should  be 
either  the  port  location  along  with  the  DTG  for  arrival  and  departure  for  a  BSF,  or  the 
oiler  ID,  RAS  rendezvous  latitude  and  longitude  and  DTG. 
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Message 

Type 

Plan  ID 

Point  # 

Point 

Type 

Ship 

ID 

Port 

ID 

Latitude 

Longitude 

DTG 

2 

DDG69000101 

1 

Port 

N/A 

203 

N/A 

N/A 

16-Feb- 
2011,  0730z 

2 

DDG69000101 

2 

RAS 

TAKE1 

N/A 

36°34’59”N 

6°20’35”W 

19-Feb- 
2011,  0930z 

2 

DDG69000101 

3 

Port 

N/A 

506 

N/A 

N/A 

23 -Feb- 
2011,  1900z 

2 

DDG69000101 

4 

RAS 

N/A 

50°47’20”N 

1°06’36”W 

23-Feb- 
2011,  1900z 

2 

DDG69000101 

5 

Port 

TAOE6 

506 

N/A 

N/A 

4-Mar-2001, 

1600z 

2 

DDG69000101 

. 

# 

# 

# 

# 

# 

2 

DDG69000101 

# 

. 

2 

DDG69000101 

• 

• 

. 

• 

. 

Table  4.  Summary  table  of  potential  refueling  points  from  the  FSMD  to  the  NFMS 

CONUS  server. 

c.  Build  Transportation  Network 

At  this  point,  the  NFMS  CONUS  server  has  the  data  it  needs  to  begin  the 
transportation  network  analysis  to  find  the  optimal  path.  Every  combination  of  refueling 
waypoints  and  fixed  voyage  plan  waypoints  will  be  paired  as  individual  links  in  the 
overall  plan.  Each  pairing  will  be  sent  to  the  FNMOC  AOTSR  route  generator  service  to 
obtain  the  predicted  courses  and  speeds,  which  can  then  be  used  to  calculate  the  weight  of 
the  links  in  the  transportation  analysis.  The  FNMOC  AOTSR  is  a  production  system 
with  established  input  and  output  schemas. 

Figure  2  is  an  example  of  the  input  required  for  the  FNMOC  ATOSR 
route  generator  Web  service.  The  original  example  had  10  waypoints.  Figure  2  has 
points  3-10  removed  to  demonstrate  how  the  Web  service  can  be  used  to  obtain  the 
course  and  speed  between  two  points.  Note,  the  ship’s  class  is  input  to  the  Web  service, 
since  the  model  the  service  uses  to  predict  course  and  speed  includes  draft  and  sail  area  of 
a  particular  ship  class.  This  is  because  winds  and  currents  affect  each  ship  class 
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differently.  This  means  that  the  return  predicted  course  and  speeds  will  be  more  accurate 
than  the  standard  PIM  model  used  today  to  calculate  future  burn  rates.  The  Web  service 
also  takes  input  and  output  in  an  XML  format.  Since  XML  is  already  used  to  define  the 
interface  for  the  route  generator  Web  service,  in  order  to  maintain  interoperability,  NFMS 
CONUS  server,  NFMS  ship  server,  and  the  FSMD  should  also  use  XML  as  the  baseline 
ontology  and  passing  information  between  services.  A  route  generation  request  will  be 
sent  for  each  pair  of  waypoints  in  the  transportation  network  built  by  the  FNMOC 
CONUS  server. 


22 


<RouteGenRequest> 

<RequestId>MOVREP260_200801072354</RequestId> 

<Classification> 

<Level>UNCLASSIFIED</Level> 

<Caveat>FOUO</ Caveat> 

<Der ivation>Derived  From:  </Derivation> 

<Declass>None</Declass> 

</ Classification 

<Reque st Type >WEAX< /Request Type > 

<Descr iption>AOTSR  Request  to  Generate  Route  for  MOVREP  id : 2 60</Description> 
<Passage>PORT :  USA, WA, Seattle  (47-36N, 122-20W)  to  PORT:  USA, CA, San  Diego  (32- 
43N, 117-11W) </Passage> 

<Units>english</Units> 

<ShipInf o> 

<Ship>RAINIER</Ship> 

<Class>UNK  0</Class> 

<ForeDraf t>l 4 . 0</ForeDraf t> 

<AftDraft>14 . 0</AftDraft> 

<MaxHeadSea>12 . 0</MaxHeadSea> 

<MaxBeamSea>12 . 0</MaxBeamSea> 

<MaxFollowSea>12 . 0</MaxFollowSea> 

<MaxTrueWind>35 . 0</MaxTrueWind> 

<MaxRelWind>35 . 0</MaxRelWind> 

<MaxSpeed>12 . 0</MaxSpeed> 

</ShipInfo> 

<DepDTG>2 008  01 07  234  6</DepDTG> 

<ArrDTG>200801151946</ArrDTG> 

<Models> 

<WindModel>NOGAPS</WindModel> 

<WaveModel >WW3_GLOBAL< /WaveModel > 

<CurrentModel>TOPS_GLOBAL</CurrentModel> 

</Models> 

<Points> 

<Point> 

<PointId>l</PointId> 

<WpN umber >12 10</WpNumber> 

<Latitude>47 . 6</Latitude> 

<Longitude>-122 . 33333333333333</Longitude> 

<DTG>2 00801072 34 6</DTG> 

</Point> 

<PointId>2</PointId> 

<WpN umber >12 ll</WpNumber> 

<Latitude>48 . 4</Latitude> 

<Longitude>-122 . 9</Longitude> 

<DTG>2 0080108074 6</DTG> 

</Point> 

</Points> 

</RouteGenRequest> 


Figure  2.  XML  schema  from  NFMS  CONUS  server  to  FNMOC  Route  Generator 

Web  Service.  From  [6]. 


Once  the  AOTSR  route  generator  has  generated  the  route  for  each  pairing 
of  waypoints  the  infonnation  returned  will  be  as  shown  in  Figures  3-5.  This  sample 
output  was  provided  by  FNMOC  Monterey  with  Waypoints  3-10.  The  AOTSR  route 
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generator  service  can  accept  more  than  two  points,  and  may  return  more  than  two  points 
for  each  pairing  of  waypoints.  The  sample  output  is  broken  down  into  header 
information  and  point  infonnation. 


<RouteGetResponse> 

<ResponseStatus><Success/>< /Responses tatus> 

<Classif ication> 

<Level>UNCLASSIFIED</Level> 

<Caveat>FOUO</ Caveat > 

<Derivation>Derived  From: </Derivation> 

<Declass>None</Declass> 

</Classif ication> 

<Header> 

<RequestId>MOVREP260_200801072354</RequestId> 

<RequestType>WEAX</RequestType> 

<Description>AOTSR  Request  to  Generate  Route  for  MOVREP  id: 260</Description> 
<Passage>PORT :  USA, WA, Seattle  ( 47-36N, 122-20W)  to  PORT:  USA, CA, San  Diego  (32-43N,117- 

11 

<Units>english</Units> 

<CreationDate>02/05/2008</CreationDate> 

<CreationTime>00 : 04 : 38</CreationTime> 

<Ship>RAINIER</Ship> 

<DepartureDate>01/08/2008</DepartureDate> 

<DepartureTime>00 : 45 : 00</DepartureTime> 

<TimeEnroute>187 . 75</TimeEnroute> 

<DistanceEnroute>1339 . 24</DistanceEnroute> 

<PowerEnroute>136 . 38</PowerEnroute> 

<RequiredSpeed>7 . l</RequiredSpeed> 

<Models> 

<WindModel>NOGAPS</WindModel> 

<WaveModel>WW3_GLOBAL</WaveModel> 

<CurrentModel>TOPS_GLOBAL</CurrentModel> 

</Models> 

</Header> 


Figure  3.  Sample  output  from  FNMOC  Route  Generator  Web  Service  (header). 

From  [6]. 
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<PointsList> 

<Point> 

<PointId>l</ Point Id> 

<WpNumber>1210</WpNumber> 

<DTG>200801080045</DTG> 

<Latitude>47 . 600</Latitude> 

<Longitude>-122 . 333</Longitude> 

<NavType>GC</NavType> 

<ShipSpeed>6 . 60</ShipSpeed> 

<ShipCourse>334 . 85</ShipCourse> 

<WindSpeed>14 . 60</WindSpeed> 

<WindDirection>343 . 77</WindDirection> 

<SigWaveHeight>0 . 00</SigWaveHeight> 

<SeaHeight>0 . 00</SeaHeight> 

<SeaPeriod>0 . 00</SeaPeriod> 

<SeaDirection>0 . 00</SeaDirection> 

<SwellHeight>0 . 00</SwellHeight> 

<SwellPeriod>0 . 00</SwellPeriod> 

<SwellDirection>0 . 00</SwellDirection> 

<CurrentSpeed>0 . 00</CurrentSpeed> 

<CurrentDirection>0 . 00</CurrentDirection> 
<EnvironLimits> 

<MinDist35></MinDist35> 

<MinDist50></MinDist50> 

<RelWind>0</RelWind> 

<SwlHtBeam>0</SwlHtBeam> 

<SwlHtFollow>0</SwlHtFollow> 

<SwlHtHead>0</SwlHtHead> 

<TrueWind>0</TrueWind> 

<WvHtBeam>0</WvHtBeam> 

<WvHtFollow>0</WvHtFollow> 

<WvHtHead>0</WvHtHead> 

<DepthWrngs>Land</DepthWrngs> 

</EnvironLimits> 

<HorsePower>l . 33</HorsePower> 

<Distance>34 . 54</Distance> 
<WindSource>Climatology</WindSource> 

<WaveSour ce>Climatology</ Wave Sour ce> 

<CurrentSource>TOPS_GLOBAL-2008020400</CurrentSource> 

</Point> 


Figure  4.  Sample  output  from  FNMOC  Route  Generator  Web  Service  (pointl). 

From  [6]. 
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<Point> 

<PointId>2</PointId> 

<WpNumber></WpNumber> 

<DTG>200801080600</DTG> 

<Latitude>48 . 121</Latitude> 

<Longitude>-122 . 700</Longitude> 

<NavType>GC</NavType> 

<ShipSpeed>6 . 60</ShipSpeed> 

<ShipCourse>334 . 58</ShipCourse> 

<WindSpeed>14 . 48</WindSpeed> 

<WindDirection>351 . 77</WindDirection> 

<SigWaveHeight>0 . 00</SigWaveHeight> 

<SeaHeight>0 . 00</SeaHeight> 

<SeaPeriod>0 . 00</SeaPeriod> 

<SeaDirection>0 . 00</SeaDirection> 

<SwellHeight>0 . 00</SwellHeight> 

<SwellPeriod>0 . 00</SwellPeriod> 

<SwellDirection>0 . 00</SwellDirection> 

<CurrentSpeed>0 . 00</CurrentSpeed> 

<CurrentDirection>0 . 00</CurrentDirection> 
<EnvironLimits> 

<MinDist35></MinDist35> 

<MinDist50x/MinDist50> 

<RelWind>0</RelWind> 

<SwlHtBeam>0</SwlHtBeam> 

<SwlHtFollow>0</SwlHtFollow> 

<SwlHtHead>0</SwlHtHead> 

<TrueWind>0</TrueWind> 

<WvHtBeam>0</WvHtBeam> 

<WvHtFollow>0</WvHtFollow> 

<WvHtHead>0</WvHtHead> 

<DepthWrngs></DepthWrngs> 

</EnvironLimits> 

<HorsePower>0 . 71</HorsePower> 

<Distance>18 . 58</Distance> 
<WindSource>Climatology</WindSource> 

<WaveSour ce>Climatology</ Wave Sour ce> 

<CurrentSource>TOPS_GLOBAL-2008020400</CurrentSource> 

</Point> 

</ Point sList> 

</RouteGetResponse> 


Figure  5.  Sample  output  from  FNMOC  Route  Generator  Web  Service  (point2). 

From  [6]. 

The  route  generator  Web  service  provides  significantly  more  infonnation 
than  is  needed  for  the  NFMS  to  find  an  optimum  track.  This  is  another  reason  underlying 
the  proposed  physical  architecture.  Since  a  large  number  of  these  relatively  small 
messages  will  be  required  in  order  to  obtain  all  the  weights  for  the  links  in  the 
transportation  network  analysis,  rather  than  filling  up  the  limited  bandwidth  from  shore  to 
ships  resource,  we  locate  a  central  server  in  CONUS  where  bandwidth  is  virtually 
unlimited  and  these  infonnation  flows  can  be  absorbed  with  relatively  little  impact  upon 
the  CONUS  infrastructure.  The  NFMS  CONUS  server  serves  two  functions.  First,  it  is 
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an  intermediate  processor  handling  all  the  function  calls  to  the  other  CONUS  based 
servers,  building  the  plan  and  sending  only  the  information  needed  by  the  ships,  the 
optimized  plan.  Second,  NFMS  will  act  as  a  condition  monitor,  which  continuously 
monitors  the  current  optimal  plan  and  only  sends  data  to  the  ships  if  the  state  of  the  plan 
changes. 

The  only  information  the  NFMS  CONUS  server  needs  to  obtain  the  link 
weights  are  the  speeds  at  each  of  the  points  for  each  of  the  pairings  of  waypoints  and 
their  associated  distance.  The  transportation  network  route  generator  must  pre-process 
and  sum  the  gallons  burned  along  each  point  to  obtain  the  weights  for  each  link.  The 
preprocessing  section  of  Chapter  IV  will  go  into  detail  on  how  this  conversion  takes 
place. 

Once  the  transportation  network  is  built,  the  optimal  path  discovery 
method  described  in  Chapter  IV  will  be  executed.  The  optimal  path  will  then  be  returned 
to  the  ship  server,  using  the  same  ID  for  the  initial  fuel  plan.  This  optimal  plan  should 
include  estimated  fuel  percentages  at  each  stop.  An  example  of  this  data  is  as  follows: 
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Mess 

age 

Type 

Plan  ID 

Point  # 

Point 

Type 

Ship 

ID 

Port 

ID 

Latitude 

Longitude 

Arrive 

Depart 

Arrive 

Fuel 

% 

Depart 

Fuel 

% 

3 

DDG69 

000101 

1 

Port 

N/A 

569 

N/A 

N/A 

N/A 

01-Jan- 

2011, 

0830z 

N/A 

83% 

3 

DDG69 

000101 

2 

Port 

N/A 

801 

N/A 

N/A 

08-Jan- 

2011, 

lOOOz 

1 1-Jan- 
2011, 
1200z 

53% 

98% 

3 

DDG69 

000101 

3 

Port 

N/A 

203 

N/A 

N/A 

16- Jan- 
2011, 
0900z 

18-Jan- 

2011, 

1200z 

83% 

83% 

3 

DDG69 

000101 

4 

RAS 

1 

N/A 

50°47’20”N 

1°06’36”W 

21 -Jan- 
2011, 
0200z 

21-Jan- 

2011, 

0500z 

46% 

98% 

3 

DDG69 

000101 

5 

Port 

N/A 

506 

N/A 

N/A 

5-Feb- 

2011, 

1215z 

12-Feb- 

2011, 

1300z 

57% 

98% 

3 

DDG69 

000101 

6 

RAS 

2 

N/A 

50°47’20”N 

1°06’36”W 

15-Feb- 

2011, 

1200z 

15 -Feb- 
2011, 
1500zz 

55% 

98% 

3 

DDG69 

000101 

7 

Port 

N/A 

538 

N/A 

N/A 

28-Feb- 

2011, 

1500z 

08 -Mar- 
2011, 
lOOOz 

80% 

75% 

3 

DDG69 

000101 

8 

Port 

N/A 

301 

N/A 

N/A 

15 -Mar- 
2011, 
0800z 

19-Mar- 

2011, 

1045z 

50% 

98% 

3 

DDG69 

000101 

9 

RAS 

3 

N/A 

50°47’20”N 

1°06’36”W 

28-Mar- 

2011, 

1500z 

28-Mar- 

2011, 

1800z 

20% 

98% 

3 

DDG69 

000101 

10 

Port 

N/A 

569 

N/A 

N/A 

31 -Mar- 
2011, 
0800z 

N/A 

90% 

N/A 

Table  5.  Summary  table  of  optimized  plan  from  NFMS  CONUS  server  to  ship. 


This  table  will  be  transmitted  in  the  form  of  an  XML  message  and  will  be 
displayed  by  the  ship  server  into  a  map-based  GUI  that  the  user  will  be  better  able  to 
understand  than  reading  text.  Also,  different  reports  will  be  available  to  the  user  to 
determine  whether  the  ship  is  on  or  off  the  optimum  voyage  fuel  plan.  GUI  interfaces 
and  reports  are  described  in  Chapter  V. 

Figure  6  shows  the  information  flows  for  initial  plan  creation  in  the 
“swimming  lane”  framework  commonly  used  in  information  systems  requirements 
analysis. 
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Figure  6.  NFMS  information  flow  for  initial  plan. 
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2. 


Periodic  Fuel  Plan  Check  Initiated  at  CONUS  Server 


a.  Initial  Conditions 

Once  the  initial  plan  is  created,  it  will  need  to  be  updated  periodically  by 
the  CONUS  server.  Having  the  plan  check  initiated  at  the  CONUS  server  provides  three 
benefits: 

1)  It  minimizes  the  amount  of  traffic  being  sent  from  the  ship  to  the 
CONUS  server. 

2)  Ships  routinely  operate  at  EMCON  (emissions  control),  which  is  a  state 
where  all  electronic  communication  is  shut  off  to  minimize  emissions  that 
can  be  used  for  tracking  the  ship’s  movements.  Therefore,  when  the  ship 
is  up  and  available  to  receive  information,  the  new  plan  will  be  waiting  to 
be  “pushed”  to  the  ship. 

3)  Since  the  ship  receives  the  new  plan  without  having  to  initiate  a 
connection,  it  also  minimizes  the  amount  of  time  the  ship  has  to  wait  for 
the  new  plan. 

Weather  can  change  on  an  hourly  basis;  however,  it  would  not  be  practical 
to  update  the  plan  on  an  hourly  basis  or  even  on  an  every- 12-hour  basis  as  forecasts  are 
updated.  If  a  stonn  develops  unexpectedly,  the  ship  must  deal  with  avoiding  the  storm 
first,  and  then  initiate  a  check  of  the  plan  after  the  storm  has  been  avoided.  Also,  it  is  not 
feasible  to  change  ports  or  develop  RAS  on  the  fly,  with  less  than  36-48  hours’  notice. 
This  is  one  of  the  main  reasons  to  have  a  planning  system  such  as  NFMS.  It  eliminates 
the  need  for  last-minute  changes  while  optimizing  the  voyage  for  overall  fuel 
conservation.  Therefore,  a  24-hour  cycle  is  recommended  for  the  CONUS  server  to 
initiate  a  check  of  the  plan.  Also,  the  first  48  hours  of  the  plan  should  be  locked  in, 
without  the  ability  to  be  changed  in  order  to  avoid  last-minute  changes  to  the  plan.  The 
only  exception  to  this  should  be  if  a  planned  stop  changes  in  the  FSMD,  or  the  shipboard 
user  purposefully  changes  a  fixed  waypoint. 
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b.  Steps  for  24-Hour  Cyclical  Fuel  Plan  Check 

The  following  steps  will  take  place  in  fuel  plan  monitoring  mode: 

1.  While  the  plan  is  being  executed,  the  CONUS  server  will  initiate  a 
check  of  the  plan  every  24  hours. 

2.  The  CONUS  server  will  send  the  remainder  of  the  fixed  plan,  less  the 
generated  optimal  fuel  stops,  to  the  FSMD.  The  format  for  this  is 
described  in  Section  1  b  of  this  chapter. 

3.  The  FSMD  will  respond  using  the  format  described  in  Section  1  b  of 
this  chapter. 

4.  The  CONUS  server  will  then  send  all  pairings  as  described  in 
Section  1  c  of  this  chapter  to  the  FNMOC  ATOSR  Route  Generator. 

5.  The  CONUS  server  will  then  calculate  all  the  links  for  the  analysis  and 
optimization  model  that  is  described  in  Chapter  IV. 

6.  The  CONUS  server  will  then  determine  any  differences  between  the 
old  plan  and  the  new  plan,  by  looking  first  whether  any  points  have 
changed,  and  second,  whether  any  amount  of  fuel  burned  has  changed 
between  points.  If  the  old  plan  is  nearly  identical  to  the  new  plan  with 
only  minor  fuel  percentage  changes,  the  message  sent  to  the  ship 
server  need  only  be  a  small  subset  of  the  overall  new  plan.  An 
example  follows: 
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Message 

Type 

Plan  ID 

Point 

# 

Change/No- 

Change 

Point 

Type 

Ship 

ID 

Port 

ID 

Latitude 

Longitude 

Arrive 

Depart 

Arrive 

Fuel 

% 

Depart 

Fuel 

% 

4 

DDG69000102 

1 

No-Change 

4 

DDG69000102 

2 

No-Change 

4 

DDG69000102 

3 

Change 

80% 

80% 

4 

DDG69000102 

4 

Change 

52% 

98% 

4 

DDG69000102 

5 

No-Change 

4 

DDG69000102 

6 

Change 

60% 

98% 

4 

DDG69000102 

7 

No-Change 

4 

DDG69000102 

8 

No-Change 

4 

DDG69000102 

9 

No-Change 

4 

DDG69000102 

10 

No-Change 

Table  6.  Summary  table  of  NFMS  CONUS  Server  fuel  plan  update  to  ship. 

In  Table  6,  it  can  be  seen  that  only  the  changed  information  is  populated  in 
the  table,  because  this  table  will  be  the  basis  from  which  the  XML  message  will  be 
formed  to  pass  from  the  NFMS  CONUS  server  to  the  receiving  ship.  If  the  actual 
locations  or  dates  of  the  plan  had  changed,  then  those  fields  would  be  filed  with  the 
updated  information.  The  sequence  number  DDG69000101  now  changes  to 
DDG69000102  because  the  predetennined  fuel  percentages  changed,  which  results  in  a 
new  current  plan  on  the  CONUS  sever.  This  ID  methodology  keep  the  plans  organized 
and  allows  only  the  most  recent  plan  in  execution  to  be  tracked  every  24  hours  for 
weather  pattern  prediction  updates.  This  also  provides  a  nomenclature  for  historical 
archiving  of  data  for  future  data  mining  and  tracking  the  evolution  of  fuel  planning.  If 
the  waypoints  change  more  than  a  few  percentage  differences,  a  full  new  optimal  plan,  as 
outlined  in  Section  1  c  of  this  chapter,  would  need  to  be  sent.  The  header  information  in 
the  XML  message  passed  would  indicate  type  5  for  fuel  plan  replace  with  an  ID  of 


32 


DDG69000201  in  the  same  format  as  Table  5.  This  would  let  the  ship  know  that  his  new 
plan  replaces  all  previous  versions  of  DDG690001XX. 

Figure  7  visually  describes  the  infonnation  flows  outlined  above  for  the 
24-hour  cyclical  fuel  plan  check  by  the  CONUS  server. 
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Figure  7.  NFMS  information  flow  check  plan  initiated  by  NFMS  CONUS  Server. 
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3.  Verify  Fuel  Plan  with  New  Input  Variables 
a.  Initial  Conditions 

In  addition  to  weather  changes,  ships  can  vector  off  course,  or  not  follow 
the  exact  track  predetermined  by  the  NFMS.  Also,  the  ports  of  call  can  change  in  the 
middle  of  a  voyage.  Therefore,  updated  input  variables  will  be  needed  to  be  sent  from 
the  ship  to  the  NFMS  CONUS  server  from  time  to  time  to  ensure  the  ship  is  on  plan. 
Unlike  the  weather  that  can  be  updated  on  a  periodic  basis,  i.e.,  every  24  hours,  the 
variables  from  the  ship  are  nonperiodic.  However,  updated  fuel  percentages  taken  from 
the  ships  tanks  are  required  on  a  24-hour  basis  by  operational  reporting  requirements  for 
all  fleets  when  ships  are  deployed.  Therefore,  the  updated  fuel  percentages  should  be 
input  into  the  NFMS  via  the  ship  workstation  by  the  user  every  24  hours. 

If  the  fuel  percentages  are  within  the  sensitivity  limits  of  the  optimized 
voyage  fuel  plan,  provided  the  sensitivity  analysis  data  is  on  the  ship  server,  the  ship’s 
server  will  not  send  any  infonnation  to  the  CONUS  server.  In  this  case,  the  CONUS 
server  will  not  be  waiting  for  updates  every  24  hours  from  the  ship.  If  no  updates  are 
received,  then  the  ship  is  on  plan  within  limits  and  no  further  action  is  required. 
However,  if  the  ship  is  off  plan,  and  over  the  sensitivity  limits  provided  by  the  analysis, 
then  an  update  plan  request  will  need  to  be  initiated  by  the  ship’s  server.  In  this  situation, 
the  only  parameter  changing  is  the  initial  fuel  percentage  of  the  plan.  The  CONUS  server 
knows  from  the  initial  plan  what  the  fixed  waypoints  are  for  the  voyage  and  what  the 
original  planned  route  entails.  The  following  is  an  example  of  an  input  variable  change: 


Message 

Type 

Plan  ID 

DTG 

Latitude 

Longitude 

Fuel  % 

6 

DDG69000102 

15-JAN-201 1, 
1200z 

50°47’20”N 

O 

o 

OS 

OS 

4 

75% 

Table  7.  Summary  table  of  input  variable  change  from  ship  to  NFMS  CONUS 

server. 
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Once  the  request  is  received  by  the  CONUS  server,  it  will  perform  the 
following  steps: 

1.  The  CONUS  server  sends  a  new  request  to  discover  the  potential  fuel 
points  based  on  the  new  input  variable  concatenated  with  the 
remainder  of  the  fixed  track  to  the  FSMD.  The  fonnat  for  this  is 
described  in  Section  1  b  of  this  chapter. 

2.  The  FSMD  will  respond  in  the  format  described  in  Section  1  b  of  this 
chapter. 

3.  The  CONUS  server  will  then  send  all  pairings  as  described  in  Section  1 
c  of  this  chapter  to  the  FNMOC  AOTSR  Route  Generator. 

4.  The  CONUS  server  will  then  calculate  all  the  links  for  the  analysis  and 
optimization  model  as  described  in  Chapter  IV. 

5.  The  CONUS  server  will  compare  the  old  plan  and  the  new  plan.  If  the 
old  plan  maintains  the  same  waypoints  as  the  new  plan  with  only 
minor  fuel  percentage  changes,  the  message  sent  to  the  ship  server  is 
described  in  Section  3  a  of  this  chapter. 

b.  Voyage  Plan  Fixed  Waypoint  Change 

If  the  voyage  plan  changes  entirely,  e.g.,  if  the  ship  is  no  longer  going  to 
Dubai,  or  Mallorca,  but  instead  reroutes  to  Bahrain  and  Rota,  a  new  plan  will  need  to  be 
generated.  This  will  follow  the  same  basic  structure  as  described  in  this  chapter  with  the 
following  exceptions. 

The  type  of  message  would  be  a  plan  replace.  The  old  ID  number 
DDG69000102  would  need  to  be  changed  to  a  new  plan  ID  and  would  be  described  as 
DDG69000201.  After  the  plan  ID  number  changes,  the  CONUS  server  will  place  the  old 
plan  in  archives  and  will  no  longer  be  updating  it  on  a  24-hours  basis  for  weather  pattern 
predication  updates. 
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Figure  8  displays  the  information  flows  outlined  above  for  the  input 
variable  changes  by  the  NFMS  ship  server. 


Figure  8.  NFMS  information  flow  update  variables  from  ship. 
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In  this  chapter,  we  have  specified  the  basic  network  topology  and  physical 
layout  for  the  NFMS,  taking  into  account  the  requirements  for  implementation  as  an 
SOA.  The  information  flows  we  have  developed  leverage  VIRT  principles  in  trying  to 
minimize  bandwidth  consumption  from  ship  to  shore.  The  next  chapter  provides  a  proof 
of  concept  using  Microsoft  Excel  as  an  optimization  engine  to  obtain  an  optimal  solution 
that  will  be  transmitted  to  the  ship  server. 
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IV.  TRANSPORTATION  MODEL  AND  ANALYSIS 


We  have  now  described  the  information  flows,  and  required  network 
infrastructure  to  design  the  NFMS.  NFMS  needs  to  interface  with  the  FNMOC  AOTSR 
to  tie  weather  into  the  system  providing  a  better  model  than  PIM.  NFMS  needs  to 
interface  with  FSMD  to  discover  alternate  paths.  Both  FNMOC  AOTSR  and  FSMD  also 
gives  NFMS  awareness  to  changes  in  the  environment  when  NFMS  asks  for  updated 
information.  At  its  core,  the  NFMS  is  solving  the  problem  of  the  optimal  path  in  this 
case  the  optimal  path  is  defined  as  the  most  fuel  efficient  path  that  still  gets  the  ship  to  its 
required  ports  on  time.  First,  NFMS  needs  to  convert  the  data  given  from  AOTSR  into 
the  relevant  values  to  define  the  link  weights  for  the  optimal  path. 

Figure  9  is  a  graphical  representation  of  a  notional  transportation  network.  In  this 
notional  example,  the  user  has  input  three  waypoints  that  are  fixed/hard  and  will  not 
change.  On  the  graphic,  these  fixed  points  are  noted  by  circles.  The  diamonds  represent 
the  potential  refueling  locations  returned  by  the  FSMD.  The  squares  represent  the 
waypoints  returned  by  the  FNMOC  AOTSR,  when  a  pairing  of  circles  /  circles,  circles  / 
diamonds  and  diamonds  /  diamonds  are  sent  to  the  FNMOC  AOTSR  route  generator. 
These  waypoints  are  not  set  as  a  fixed  number  as  the  AOTSR  route  generator  can  return 
any  number  of  waypoints  between  the  paring  given  as  seen  in  Figures  3-5.  As  described 
in  Chapter  III,  the  NFMS  CONUS  server  would  have  sent  these  pairings  of  user  and 
FSMD  waypoints  to  obtain  the  course  and  speed  due  to  weather  data  from  FNMOC 
AOTSR.  At  first,  NFMS  will  not  know  which  potential  links  to  filter  based  on  DTG, 
speed  of  vessel,  and  percent  of  fuel  to  maintain.  Therefore,  all  possible  combination  of 
pairing  will  need  to  be  passed  to  the  AOTSR  route  generator.  Then  a  filter  will  be 
applied  removing  all  unattainable  links.  Unattainable  links  are  ones  where  the  ship  will 
run  out  of  fuel,  go  below  the  required  fuel  percentage  to  maintain,  and  cannot  make  the 
associated  follow-on  nodes  based  on  maximum  ship  speed.  After  all  unattainable  links 
are  removed;  a  transportation  network  can  be  built  based  on  associated  DTGs  with  each 
node.  In  this  nominal  case  where,  NFMS  has  already  filtered  and  built  a  transportation 
network  with  the  following  ordered  pairs:  (1,2)  (1,3)  (1,4)  (2,5)  (2,3)  (3,4)  (3,5)  (4,5) 
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(5,6)  (5,7)  (5,9)  (6,7)  (6,9)  (7,9)  (7,8)  and  (8,9).  These  represent  16  different  calls  to  the 
AOTSR,  each  of  which  can  return  any  number  of  intermediate  waypoints,  since  the 
AOTSR  route  generator  defines  a  waypoint  as  a  turn  or  change  in  speed  due  to  weather  or 
land  avoidance.  Links  need  to  be  built  between  the  intennediate  waypoints,  and  assigned 
weights.  These  weighted  links  will  be  summed  to  arrive  at  a  single  link  weight  across 
Lij. 
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A.  MODEL  PREPROCESSING  REQUIREMENTS 

The  data  collected  from  the  AOTSR  route  generator  is  in  the  form  of  speed  in 
knots  between  waypoints.  These  intermediate  waypoints  can  each  have  differing  speeds 
to  reach  them  on  time;  these  different  waypoints  are  noted  as  Wk.  Therefore,  the  NFMS 
CONUS  server  needs  to  have  a  database  of  fuel  bum  curves.  These  fuel  consumption 
charts  differ  based  on  ship  class,  i.e.,  DDG,  CG,  FFG,  LPD,  LPD-17,  LHD,  LHA,  or 
LHD.  The  curves  define  specific  fuel  burn  amounts  in  gallons  per  hour  based  on  ships 
ordered  speed  in  knots  and  plant  configuration.  These  types  of  curves  can  be  seen  in  the 
NAVSEA  Incentivized  Energy  Conservation  Program  Web  site  in  both  data  only  and 
graphed  from  [7].  Figure  10  and  Table  8  are  examples  of  reference  data  obtained  on  a 
DDG  51  class  vessel. 
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Figure  10.  Fuel  Curve  of  DDG  51  Class  (FLT.  IIA)  Total  Ship  Fuel  Consumption 

(GPH)  (with  Stern  Flap).  From  [7]. 
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DDG  51  CLASS  (FLT.  IIA)  TOTAL  SHIP  FUEL  CONSUMPTION 

(With  Stern  Flap) 


Source:  Final  Report  USS  Oscar  Austin  (DDG  79)  Performance  and  Special  Trials  Results 
SEPTEMBER  2001 
Displacement  =  9,150  LT 

For  displacement  changes  modify  SH P  by  +/-  3.5%  per  +/-  100  LT  change 

Average  24-Hour  Load  =  1  ,900  kW(324  GPH)from  NAVSEASECAT  report  aboard  USS 

McFAUL  (DDG  74) 

For  kW  changes  modify  GPH  by  +/-  El  GPH  per  +/-  1 00  kW  change 
No  Bleed  Air 

GPH  =  Gallons  per  hour;  GPNM  =  Gallons  per  nautical  mile 
Trail  shaft  data  is  applicable  to  100%  and  80%  propeller  pitch 


Table  8.  Fuel  Data  table  of  DDG  51  Class  (FLT.  IIA)  Total  ship  fuel  consumption 

(GPH)  (with  Stern  Flap).  From  [7], 
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Research  has  been  done  identifying  the  most  economical  plant  configuration  to  be 
used  for  a  given  speed.  These  recommended  plant  configurations  should  be  used  by  the 
NFMS  CONUS  server  to  obtain  an  accurate  fuel  plan  [8]. 

Once  the  fuel  curve  databases  are  populated  on  the  NFMS  CONUS  server,  then  it 
is  a  simple  table  look  up  to  determine  the  speed  required  to  reach  each  waypoint,  which 
will,  in  turn,  determine  how  much  fuel  is  burned  per  hour.  Dividing  the  speed  to  reach 
each  intermediate  waypoint  by  the  distance  (both  provided  by  the  AOTSR  route 
generator  service)  will  yield  how  long  the  ship  will  take  to  reach  each  intermediate 
waypoint.  Multiplying  the  time  to  reach  the  intermediate  waypoint  by  the  amount  of  fuel 
burned  per  hour  will  yield  the  amount  of  fuel  burned  to  reach  each  intermediate 
waypoint.  This  amount  of  fuel  burned  to  get  to  each  intennediate  waypoint  is  summed  to 
get  to  the  weight  for  the  links  between  each  identified  refueling  location  in  the 
transportation  problem  analysis  (see  Figure  1 1  for  the  mathematical  representation). 
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From  the  information  provided  from  the  AOTSR  route  generator: 

For  a  given  link  L,j 

•  Define  intermediate  waypoints  Wk,  k  =  0,m  with  Wo  being  the  starting 
node  i  on  link  L,j,  and  Wm  being  the  ending  node  j  on  link  L,,. 

For  each  intermediate  waypoint  Wk.  in  Ly,  let 

•  Ak  =  the  speed  used  to  get  to  intennediate  waypoint  Wk  from  Wk-i  in 
nautical  miles  per  hour  (knots). 

•  2?k  =  the  distance  from  intermediate  waypoint  Wk-i  to  Wk  in  nautical 
miles. 

•  Ck  =  Gallons  of  fuel  burned  per  hour  transiting  from  Wk-i  to  Wk.  Note 
that  Au  can  be  used  to  get  Ck  from  the  database  fuel  consumption  charts 
for  a  given  speed  for  a  given  ship  class. 

•  Z>k  =  Gallons  of  fuel  used  to  transit  from  Wk-i  to  Wk. 

Dk  =  (Ak  -T-  Bk)  x  Ck 

Z>y  =  Gallons  of  fuel  used  across  the  entire  link  Ly 

D„  =  I  Dt 

k 

Figure  1 1 .  Mathematical  pre-processing  requirements. 
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B. 


MATHEMATICAL  MODEL  FOR  SOLVING  SHORTEST  PATH 


Once  the  link  weights  are  determined  by  using  the  logic  in  Figure  1 1,  a  repeatable 
model  will  need  to  be  used  to  derive  the  shortest  path.  This  shortest  path  will  be  the  most 
efficient  or  optimized  route  a  ship  should  take  based  on  fuel  burned.  Figure  12  is  a  well- 
known  way  to  solve  for  the  shortest  path  [9]. 


Let 

1  =  Source  node,  the  designated,  fixed  starting  node 
S  =  Sink  node,  the  designated,  fixed  ending  node 
Xy  =  1  if  the  link  ij  should  be  travelled,  0  otherwise 
Ly  =  Weight  for  linkXij 


mm 


Xu 


X LijXij 


Subject  to 

I>,  =  1 

j 

Xin  ~  ^  Xnj  =  0  \f  n,  i  ^  l,  j  ^  S 

i  J 

YXis  =  -\ 


Figure  12.  Generic  mathematical  model  for  solving  shortest  path. 
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C.  SOLVING  WITH  MICROSOFT  EXCEL:  PROOF  OF  CONCEPT 

Microsoft  Excel  contains  a  built-in  solver  that  can  optimize  the  model  represented 
in  Figure  12  for  small  problems,  typically  networks  of  50  nodes  or  less.  We  present  an 
example  problem,  based  on  hypothetical  data,  which  will  serve  as  a  proof  of  concept  for 
the  fuel  optimization  model.  The  proof  of  concept  may  be  accessed  by  clicking  the  paper 
clip  icon  visible  on  the  lower  left-hand  comer  of  your  screen.  Ensure  Adobe  Acrobat  is 
set  up  to  open  non-PDF  attachments  (Edit,  Preferences,  Trust  Manager).  Alternatively, 
you  may  save  the  Excel  file  to  your  hard  drive  in  order  to  open  it. 

In  our  proof-of-concept  example,  a  user  on  a  DDG  5 1  Class  ship  is  setting  out  to 
plan  the  fuel  stops  from  a  homeport  in  Norfolk,  VA,  to  the  Port  of  Mallorca,  Spain, 
ending  in  Dubai.  (We  assume  all  DTG  will  be  set  to  1200z  to  simplify  the  math  involved 
in  calculating  gallons  for  weights  of  links.  This  way,  integral  24-hour  days  will  be  used.) 


Waypoint 

Name 

Latitude 

Longitude 

Arrive 

Depart 

Norfolk  (1) 

36°59’33”N 

76°20’32”W 

- 

01  JAN  2011 

Mallorca  (4) 

39°19’45”N 

2°55’14”E 

15  JAN  2011 

18  JAN  2011 

Dubai(9) 

25°17’22”N 

55°16’13”E 

10  FEB  2011 

- 

Table  9.  User  Input  to  Proof  of  Concept. 


From  the  data  calls  described  above,  the  notional  data  in  Table  10  is  a 
representation  of  the  infonnation  returned  by  the  FSMD.  To  simplify  calculations,  the 
time  spent  refueling  will  be  assumed  to  be  zero  even  though  in  reality  it  takes 
approximately  2-3  hours  to  come  alongside  and  refuel.  Typical  refueling  speed  is  13 
knots  at  full  power  for  restricted  maneuvering.  Using  Table  8,  it  can  be  detennined  that  a 
DDG  will  bum  1196  gallons  of  fuel  per  hour  alongside.  This  is  also  typically  on  a  course 
set  into  the  seas  for  a  smother  refueling  operation.  This  time  spent  refueling,  therefore, 
causes  an  increase  in  speed  necessary  to  get  to  the  next  waypoint  on  schedule,  along  with 
the  excessive  fuel  consumption  while  at  full  power.  In  an  actual  application,  these 
calculations  should  be  taken  into  account  so  that  the  most  accurate  fuel  usage  estimates 
can  be  used  to  optimize  a  fuel  plan. 
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Waypoint 

Name 

Latitude 

Longitude 

Arrive 

Depart 

RAS  (2) 

37°68’34”N 

10°49”17”W 

12  JAN  2011 

12  JAN  2011 

RAS  (3) 

37°16’39”N 

0°15’13”E 

14  JAN  2011 

14  JAN  2011 

RAS  (5) 

32°41’28”N 

26°28’29”E 

24  JAN  20 11 

24  JAN  2011 

Cyprus  (6) 

34°45’7”N 

33°34’49”E 

26  JAN  2011 

26  JAN  2011 

Djibouti  (7) 

1 1°29’1”N 

43°13’56”E 

02  FEB  2011 

02  FEB  2011 

RAS  (8) 

15°37’12”N 

57°31’45”E 

05  FEB  2011 

05  FEB  2011 

Table  10.  Notional  data  returned  by  FSMD. 


The  transportation  network  diagram  in  Figure  13  can  be  derived  by  using  the 
dates  available  for  refueling.  The  numbers  are  sequential  and  do  not  necessarily  require 
they  be  followed  in  order  to  determine  the  shortest  path.  It  is  important  to  note  that  the 
waypoint  names  would  be  resolved,  as  noted  in  Chapter  III,  with  a  database  of  known 
port  names  and  locations.  This  ensures  that  only  the  port  ID  need  be  passed,  minimizing 
bandwidth  utilization.  The  numbers  and  names  described  in  Tables  10  and  11  are 
numbered  to  better  label  the  nodes  on  Figure  13. 
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Figure  14  shows  a  screen  shot  using  Google  Earth  to  approximate  distances, 
avoiding  land  and  taking  direct  routes.  The  tracks  can  be  seen  coming  from  Norfolk, 
Virginia  /  node  1  into  refueling  node  2.  The  subsequent  nodes  are  labeled  on  Figure  14. 


Figure  14.  Proof  of  concept  displayed  on  Google  Earth. 

Table  1 1  is  a  summary  the  distances,  days,  hours,  speeds,  fuel  burn  rates,  and  fuel 
consumptions  of  the  proof  of  concept  from  Excel.  The  total  fuel  burned  is  a  combination 
of  the  fuel  used  for  moving  the  ship  through  the  water  from  the  gas  turbine  engines 
(GTE)  and  the  fuel  used  by  the  gas  turbine  generators  (GTG)  to  provide  electricity.  An 
average  of  280  gallons  per  hour  (GPH)  was  used  for  the  GTG  to  take  into  account 
changing  GTGs  or  operating  on  more  than  one  GTG  for  short  periods  of  time.  The 
amount  of  fuel  burned  by  the  GTGs  was  found  in  the  Shipboard  Energy  Conservation 
Guide  [10].  Figure  15  is  the  fuel  burn  rate  chart  for  DDG  51  class  ships. 
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ALLISON  MODEL  501-K34 


DDG  5 1  CLASS  FUEL  RATE  NOMOGRAM 


Figure  15.  GTG  fuel  burn  rate.  From  [10]. 
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From 

To 

Distance 

Days 

Hours 

Speed  (knots) 

GPH 

Fuel 

Fuel  burned 

Total 

Speed 

(NM) 

burned 

GTG 

Fuel 

Coefficetn 

GTE 

(Gallons) 

Burned 

Day  Depart 

Day  Arrive 

due  to  v.eath 

i 

4 

3,868 

14 

336 

11.5 

748.77 

251,588 

94,080 

345, 66S 

1-Jan-11 

15-Jan-11 

1 

4 

9 

4.722 

22 

528 

8.9 

653.S7 

345,244 

147, S40 

493, 0S4 

18-Jan-11 

10-Feb-11 

1 

i 

2 

3,082 

u 

264 

11.7 

753.33 

19S,SS0 

73,920 

2’2,800 

1-Jan-11 

12-Jan-11 

1 

i 

3 

3,672 

13 

312 

11.8 

757.97 

236,485 

87360 

323,845 

1-Jan-11 

14-Jan-11 

1 

4 

795 

3 

72 

11.0 

’27.05 

52,347 

20,160 

72,507 

12-Jan-11 

15-Jan-11 

1 

3 

4 

197 

1 

24 

8.2 

635.33 

15,248 

6,720 

21.96S 

14-Jan-11 

15-Jan-11 

1 

4 

5 

1,227 

6 

144 

8.5 

642.95 

92,585 

40,320 

132,905 

18-Jan-11 

24-Jan-11 

1 

4 

6 

1,613 

8 

192 

8.4 

640.36 

122,949 

53,760 

176.709 

18-Jan-11 

26-Jan-11 

1 

4 

7 

2,950 

14 

336 

S.S 

64S.30 

2r,S2S 

94,080 

311,908 

18-Jan-11 

2-Feb-11 

1 

4 

8 

3,739 

17 

408 

9.2 

659.63 

269,146 

114,240 

383,386 

18-Jan-11 

5-Feb-11 

1 

5 

9 

3,497 

16 

384 

9.1 

659.63 

253,314 

107,520 

360,  S34 

24-Jan-11 

10-Feb-11 

1 

6 

9 

3,371 

14 

336 

10.0 

6SS.32 

231,411 

94,080 

325,491 

26-Jan-11 

10-Feb-11 

1 

7 

9 

1,846 

8 

192 

9.6 

675.20 

129,639 

53,760 

183399 

2-Feb-11 

10-Feb-11 

1 

8 

9 

979 

5 

120 

8.2 

632.90 

75,948 

33,600 

109,548 

5-Feb-11 

10-Feb-11 

1 

5 

6 

395 

2 

48 

8.2 

635.33 

30,496 

13,440 

43,936 

24-Jan-11 

26-Jan-11 

1 

5 

7 

1,723 

8 

192 

9.0 

653.87 

125,543 

53,760 

139,303 

24-Jan-11 

2-Feb-11 

1 

5 

8 

2,395 

11 

264 

9.1 

656. ’4 

133,380 

'3.920 

243,300 

24-Jan-11 

5-Feb-11 

1 

6 

7 

1,640 

6 

144 

11.4 

339.S7 

106,541 

40,320 

146, S61 

26-Jan-11 

2-Feb-11 

1 

6 

8 

2,393 

9 

216 

11.1 

727.05 

153,042 

60,480 

217,522 

26-Jan-11 

5-Feb-11 

1 

7 

8 

875 

3 

72 

12.2 

777.24 

55,961 

20,160 

’6,121 

2-Feb-11 

5-Feb-11 

1 

Table  11.  Summary  of  distances,  days,  hours,  speeds,  fuel  burn  rates,  and  fuel 
consumption  for  proof  of  concept  transportation  network  from  Microsoft  Excel. 


Waypoint 

Name 

Latitude 

Longitude 

Arrive 

Depart 

Norfolk(l) 

36=59’33”N 

76°20!32” 

W” 

* 

1- Jan- 11 

Mallorca(4) 

39=19’45”N 

2=55T4"E 

15- Jan- 11 

IS- Jan- 11 

Dubai(9) 

25°17!22”N 

55=16'13” 

E 

10-Feb-ll 

* 

Table  12.  Summary  of  user  input  for  proof  of  concept  in  Microsoft  Excel. 


Waypoint 

Name 

Latitude 

Longitude 

Arrive 

Depart 

RAS  (2) 

37=6S;34"N 

10°49”17”W 

12-Jan-ll 

12-Jan-ll 

RAS  (3) 

37°16’39”N 

0=15T3"E 

14- Jan- 11 

14- Jan- 11 

RAS  (5) 

32=41  2S'7NT 

26=2S'29':E 

24-Jan-ll 

24-Jan-ll 

Cyprus  (6) 

34°45!7”N 

33=34"49'F 

26-Jan-ll 

26-Jan-ll 

Djibouti  (7 

11°29T”N 

43013!56”E 

2-Feb-ll 

2-Feb-ll 

RAS  (S) 

15°37’12”N 

57=3T45"E 

5-Feb-ll 

5-Feb-ll 

Table  13.  Summary  of  returned  data  from  FSMD  in  Microsoft  Excel. 
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Tables  1 1,  12  and  13  are  derived  using  the  green  cells  as  givens  from  the  proof  of 
concept  description.  Table  12  calculations  are  as  follows: 

•  Distance  is  measured  from  Google  Earth  shown  in  Figure  14. 

•  Days  used  the  Excel  function  =  DAYS360(Day  Depart,  Day  Arrive) 

•  Hours  =  Days  *  24 

•  Speed  =  (Distance/Hours)  *  Speed  Coefficient  Due  to  Weather 

•  GPH  =  VLOOKUP(sending  speed,  returning  GPH  from  Table  14) 

•  Fuel  Burned  GTG  =  Assumed  GTG  burn  fuel  average  *  Hours 

•  Fuel  Burned  GTE  =  GPH  *  Hours 

•  Total  Fuel  Burned  =  Fuel  Burned  GTG  +  Fuel  Burned  GTE 

In  order  to  obtain  a  table  look  up  accurate  to  tenths  of  a  knot  in  Excel,  a  nonlinear 
regression  must  be  run  on  the  data  from  Table  8.  By  first  plotting  the  data  in  Table  8, 
shown  by  the  red  line  in  Figure  16,  a  3ld  order  polynomial  regression  was  used  to  derive 
the  black  dashed  line  in  Figure  16.  The  3rd  order  polynomial  regression  result  is 

y  =  0.098x3  +  1.409 lx2  7.561  lx  +  571.46. 
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An  offset  must  be  applied  to  the  regression  since  the  plot  starts  at  x  =  5,  whereas, 
the  regression  starts  at  x  =  0.  Table  14  is  an  excerpt  from  the  table  in  Microsoft  Excel 
that  served  as  the  look-up  table  in  the  VLOOKUP  function. 
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Table  14.  Table  used  for  VLOOKUP  Excel  function  to  determine  GPH  from  knots 

in  Proof  of  Concept. 

55 


The  next  step  is  to  define  the  linear  program  decision  variables,  objective 
function,  and  flow  balance  equations.  For  this  proof  of  concept,  the  enumerated  decision 
variables,  objective  function,  and  the  flow  balance  equations  are  given  in  Figure  17. 


Decision  Variables  =  Xy  which  nodes  to  takes  to  get  through  the  route. 

Objective  Function  (in  gallons): 

Min(345,668  Xi4  *  493,084  X49  *  272,800  X!2  *  323,845  Xi3  *  72,507  X24  *  21,968 
X34  *  132,905  X45  *  176,709  X46  *  311,908  X47  *  383,386  X48  *  360,843  X59  * 
325,491  X69  *  183,399  X79  *  109,548  X89  *  43,936  X56  *  179,303  X57  *  247,300  X58  * 
146,861  X67  *  217,522  X68  *  76,121  X78  *  345,668  X4i  *  493,084  X94  *  272,800  X2I  * 
323,845  X3i  *  72,507  X42  *  21,968  X43  *  132,905  X54  *  176,709  X64  *  311,908  X74  * 
383,386  X84  *  360,843  X95  *  325,491  X96  *  183,399  X97  *  109,548  X98  *  43,936  X65  * 
179,303  X75  *  247,300  X85  *  146,861  X76  *  217,522  X86  *  76,121  X87) 

Flow  Balance  Equations: 

Node  Equation 

1  (X21+X31  +  X41)-(X12  +  X31  +  X14)  =  -1 

2  (X12  +  X42)-(X21  +X24)  =  0 

3  (X13  +  X43)-(X31  +X34)  =  0 

4  (Xi4  +  X24  +  X34  +  X94  +  X54  +  X64  +  X74  +  X84)  -  (X4i  +  x42  +  x43  +  x49  + 
X45  +  X46  +  X47  +  X48)  =  0 

5  (X45  +  X95  +  X65  +  X75  +  X85)  -  (X54  +  x59  +  x56  +  x57  +  X58)  =  0 

6  (X46  +  X96  +  X56  +  X76  +X86)  -  (Xg4  +  Xg9  +  X65  +  Xg7  +X68)  =  0 

7  (X47  +  X97  +  X57  +  Xg7  +  X87)  -  (X74  +  X79  +  X75  +  X76  +  X78)  =  0 

8  (X48  +  X98  +  X58  +  Xg8  +  X78)  -  (X84  +  X89  +  X85  +  X86  +  X87)  =  0 

9  (X49  +  X59  +  X69  +  X79  +  X89)  -  (X94  +  X95  +  X%  +  X97  +  X98)  =  1 


Figure  17.  Decision  Variable,  Objective  Function,  and  Flow  Balance  Equations  for 

Proof  of  Concept. 


Once  the  decision  variables,  objective  function  and  flow  balance  equations  are 
specified,  Microsoft  Excel’s  solver  can  be  used  to  find  the  shortest  path.  The  light  green 
cell  in  Table  15  is  calculated  using  the  SUMPRODETCT  function  on  the  flows  and 
gallons  tables.  The  gallons  table  in  Table  15  is  populated  using  the  Total  Fuel  Burned 
column  in  Table  11;  however,  since  DDGs  have  a  seawater  compensated  fuel  system, 
some  percentage  of  fuel  must  be  maintained  at  all  times  to  ensure  seawater  is  not 
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accidentally  injected  into  the  engines.  This  percentage  is  represented  in  the  darker  green 
square  labeled  “percent  to  maintain”  in  Table  15.  A  DDG  holds  approximately  450,000 
gallons  of  Diesel  Fuel  Marine  (DFM);  however,  Table  15  allows  this  number  to  be 
parameterized  depending  upon  ship  class.  Recall  also  that  the  fuel  bum  chart  will  change 
depending  upon  the  ship  class  so,  in  the  general  solution,  selecting  the  ship  class  should 
automatically  change  the  reference  data  used  appropriately.  Using  the  parameters 
“percentage  to  maintain”  and  “total  fuel  capacity,”  a  filter  is  applied  prior  to  populating 
the  gallons  table.  This  filter  is  applied  using  an  if  statement  in  Excel  as  follows: 

IF  ( gallons_burned<=max_fuel_used_per_link, 

THEN  gallons_bumed, 

ELSE  10000000000). 

The  default  value  10,000,000,000  is  used  to  make  the  link  weight  so  large  that  when 
compared  to  the  estimated  fuel  burned,  it  becomes  unavailable  as  a  possible  solution. 
Also,  in  Table  15  there  is  another  variable  denoted  in  darker  green,  “assumed  GTG  bum 
fuel  average,”  for  which  a  default  value  of  280  is  used  as  an  average  from  the 
incentivized  energy  conservation  program.  This  variable  also  is  a  model  parameter  that 
can  be  adjusted  if  a  given  ship  tends  to  use  more  fuel,  and  then  propagated  to  Table  11. 
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Flow  balance  equations 


Node 

Flow  in 

Flow  out 

Net  flow 

Sign 

RHS 

Node  1 

0.0 

1.0 

-1.0 

= 

-1 

Node  4 

1.0 

1.0 

0.0 

= 

0 

Node  9 

1.0 

0.0 

1.0 

= 

1 

Node  2 

1.0 

1.0 

0.0 

= 

0 

Node  3 

0.0 

0.0 

0.0 

= 

0 

Node  5 

1.0 

1.0 

0.0 

= 

0 

Node  6 

0.0 

0.0 

0.0 

= 

0 

Node  7 

0.0 

0.0 

0.0 

= 

0 

Node  8 

1.0 

1.0 

0.0 

= 

0 

Flows: 

To 

From 

N-1 

N-4 

N-9 

N-2 

N-3 

N-5 

N-6 

N-7 

N-8 

Flow  out 

Node  1 

0.0  I 

0.0 

0.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1. 

Node  4 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

0.0 

0.0 

0.0 

1. 

Node  9 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0. 

Node  2 

0.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1. 

Node  3 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0. 

Node  5 

0.0 

0.0 

o.o  L 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

1. 

Node  € 

0.0 

0.0 

o.oL 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0. 

Node  7 

0.0 

0.0 

o.oL 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0. 

Node  8 

0.0 

0.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0| 

0.0 

1. 

Flow  in 

0.0 

1.0 

1.0 

1.0 

0.0 

1.0 

0.0 

0.0 

1.0 

Least  Fuel  = 


Gallons: 

To 

From 

N-1 

N-4 

N-9 

N-2 

N-3 

N-5 

N-6 

N-7 

N-8 

Node  1 

345,668 

— jf|£M| 

272.800 

323,845 

Node  9 

mmmm 

360,834 

325,491 

J  1  1  ,“UC 

183,399 

109,548 

Node  2 

272,800 

72,507 

mmmm* 

mmmmm 

#**### 

mm# 

mmmm 

(iXiittii! 

Node  3 

323,845 

21,968 

********* 

mmm 

******** 

Node  5 

132.905 

360.834 

43.936 

179,303 

247.300 

Node  7 

311,908 

183,399 

179,303 

146.861 

76,121 

Node  8 

.(  M  i,  „  i, 

383,386 

109.548 

H  .(  ,,  H  u  ,( 

,t  M  n 

247.300 

217,522 

76,121 

■(  h  i,  i.  ff  h 

836,061 


Fuel  Capacity  = 


Percent  to  maintain  = 


Max  Fuel  Used  per  link  = 


450,000 


10% 


405,000 


<-Fuel  Capacity  of  Ship  (variable  per  class) 

<-Fuel  Percentage  to  maintain  onboard  can  set  to  mechanical  failure  or  CO  standing  c 


Assumed  GTG  burn  fuel  average  = 


280 


Table  15.  Proof  of  Concept  Solution  in  Microsoft  Excel. 


Once  the  given  darker  green  cells  are  populated,  the  solver  parameters  in  Figure 
18  can  be  used  to  derive  the  shortest  path  solution.  The  target  cell  is  the  light  green  cell 
in  Table  15  labeled  Least  Fuel.  It  is  set  equal  to  Min  because  NFMS  wants  to  minimize 
the  amount  of  fuel  used  to  achieve  the  shortest  path,  subject  to  the  constraints  in  the  array 
of  the  flow  balance  equations,  which  are  tied  into  the  flows  table  depicted  in  light  blue  in 
Table  15. 
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Figure  18.  Microsoft  Excel  solver  parameters  for  NFMS  Proof  of  Concept. 

D.  INTERPRETING  RESULTS 

Observing  the  flow  balance  equations  in  Table  15,  it  can  be  seen  the  flows  in  and 
out  for  the  nodes  equate  to  the  same  outcome  in  the  flow  balance  equations  in  Figure  17. 
This  means  that  all  constraints  and  balances  are  met  and  one  unit  will  have  traveled  from 
Node  1  to  Node  9. 

One  must  look  at  the  yellow  shaded  areas  to  determine  which  path  the  unit  must 
take  in  order  to  travel  along  the  shortest  path,  using  835,061  gallons  of  fuel  in  the 
process.  Here,  the  model  solves  the  problem  by  having  the  ship  travel  along  the 
following  route  from  node  1  node  2  ->  node  4  ->  node  5  node  8  ->  node  9.  In  real- 
world  terms  translating  from  Tables  12  and  13,  this  corresponds  to  the  fuel  plan  Norfolk 
-»  RAS  #2  -»  Mallorca  -»  RAS  #5  -»  RAS  #8  Dubai. 

E.  VALIDATION  (NFMS  AGAINST  PIM  MODEL) 

With  the  weather  coefficients  shown  in  Table  11  set  equal  to  1,  the  shortest  path 
algorithm  is  essentially  doing  a  shortest  path  analysis  on  the  PIM  model.  Weather  has 
not  been  taken  into  account.  However,  by  appropriately  changing  the  weather  coefficient 
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weight  to  simulate  a  storm  along  a  track,  which  would  cause  a  ship  following  that  track  to 
speed  up  and  use  more  fuel,  the  benefits  of  a  system  such  as  NFMS  to  the  fleet  can  be 
seen  clearly.  In  our  next  scenario,  the  weather  coefficient  is  increased  from  1  to  1.1  on 
the  links  from  Node  1  to  2  and  Node  4  to  5,  both  previous  links  in  the  first  shortest  path. 
The  change  can  be  seen  in  Table  16.  Also,  the  speed  changes  from  1 1.7  to  12.8,  and  8.5 
to  9.4  knots,  just  1  knot  difference  in  each  case.  This  corresponds  to  the  scenario 
described  in  Chapter  III  where  the  NFMS  CONUS  server  performed  a  24-hour  update  on 
an  optimal  plan,  and  the  weather  changed,  in  turn  causing  the  inputs  to  the  shortest  path 
algorithm  to  change. 


From 

To 

Distance 

(NM) 

Days 

Hours 

Speed  (knots) 

GPH 
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burned 

GTE 

Fuel  turned 

GTG 

(Gallons) 

Total 
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Day  Depart 

Day  Arrive 

Speed 

Coefficeint 

due  to  v.-eather 

1 

4 

3.S6S 

14 

336 
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74S.77 

251, 5S8 

94,080 
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1 

4 

9 
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528 
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1 

i 
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1 

3 

4 
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1 
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635.33 
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1 

4 

5 
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6 
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4 

6 

1,613 

8 
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4 
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1 

4 
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17 
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1 

5 
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16 
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8 
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Table  16.  Adding  weather  to  tracks  by  changing  weather  coefficients. 


Without  running  the  solver  again,  the  fonnulas  embedded  into  the  spreadsheet 
change  the  number  of  gallons  used  from  835,061  gallons  to  854,328  gallons.  This 
represents  an  increase  of  19,267  gallons  corresponding  to  an  increase  of  1  knot  across 
two  of  the  five  links  in  the  shortest  path  returned.  If  we  now  rerun  the  solver  with  the 
new  given  data,  a  new  shortest  path  solution  results,  as  shown  in  Table  17. 
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Flow  balance  equations 

Node 

Flow  in 

Flow  out  Net  flow 

Sign 

RHS 

Node  1 

0.0 

1.0 

-1.0 

= 

-1 

Node  4 

1.0 

1.0 

0.0 

= 

0 

Node  9 

1.0 

0.0 

1.0 

= 

1 

Node  2 

0.0 

0.0 

0.0 

= 

0 

Node  3 

0.0 

0.0 

0.0 

= 

0 

Node  5 

0.0 

0.0 

0.0 

= 

0 

Node  6 

0.0 

0.0 

0.0 

= 

0 

Node  7 

0.0 

0.0 

0.0 

= 

0 

Node  8 

1.0 

1.0 

0.0 

= 

0 

Flows: 

To 

From 

N-1 

N-4 

N-9 

N-2 

N-3 

N-5 

N-6 

N-7 

N-8 

Flow  out 

Node  1 

0.0  ■ 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

Node  4 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

1.0 

Node  9 

0.0 

0.0 

0.0 

0.0 

0.0  1 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  2 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  3 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  5 

0.0 

0.0 

o.op 

0.0 

0.0 

0.0  I 

0.0 

0,0 

0.0 

0.0 

Node  6 

0.0  ■ 

0.0 

o.op 

0.0 

0.0  I 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  7 

0.0  ' 

0.0 

O.Op 

0.0 

0.0  I 

0.0 

0.0 

0.0  j 

0.0 

0.0 

Node  8 

0.0 

0.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

Flow  in 

0.0 

1.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

Gallons: 


From 
Node  1 
Node  4 
Node  9 
Node  2 
Node  3 
Node  5 
Node  6 
Node  7 
Node  8 


To 


N-1 


N-4 


N-9 


N-2 


N-3 


N-5 


N-6 


N-7 


N-8 


345.668 


288,790 


323,845 


345,668 


72,507 


21,968 


136,182 


176,709 


311,908 


383,386 


360,834 


325,491 


183,399 


109,548 


253,790 


72,507 


323,845 


21,968 


136,182 


360,834 


43,936 


179,303 


247,300 


176,709 


325,491 


43,936 


146,861 


217,522 


311,908 


183,399 


179,303 


146,861 


76,121 


383,386 


109,548 


247,300 


217,522 


76,121 


Least  Fuel  = 


838,602 


Fuel  Capacity  = 


Percent  to  maintain  = 


Max  Fuel  Used  per  link  - 


450,000 


10% 


405,000 


<-Fuel  Capacity  of  Ship  (variable  per  class) 

<-Fue!  Percentage  to  maintain  onboard  can  set  to  mechanical  failure  or  CO  standing  ord 


Assumed GTGburn fue[avera2e^ 
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Table  17.  New  shortest  path  solution  due  to  weather  coefficient  changes. 


Examining  the  flow  balance  equations  in  Table  17  reveals  that  this  is  a  feasible 
solution  that  meets  the  constraints.  Here,  the  new  solution  can  be  seen  in  the  yellow 
highlighted  cells  indicating  a  1  for  each  link  taken:  node  1  node  4  ->  node  8  node 
9.  This  translates  to  a  shortest  fuel  plan  from  Norfolk  ->  Mallorca  ->  RAS  #8  ->  Dubai. 
The  new  optimal  solution  still  reaches  the  required  port  visits  on  time;  however,  it  bums 
only  838,602  gallons  of  fuel.  Comparing  this  to  the  854,328  gallons  required  from 
changing  the  weather  coefficients  on  the  old  optimal  solution,  we  see  a  savings  of  15,726 
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gallons.  By  using  the  NFMS  model,  one  can  manage  weather  increasing  the  cost  of  fuel 
buy  finding  more  efficient  refueling  nodes.  By  changing  our  fuel  plan  dynamically  as 
weather  data  changes,  rather  than  adhering  to  the  static  plan,  there  was  only  an  increase 
in  fuel  consumption  of  3,541  gallons  due  to  weather. 


The  NFMS  model  as  shown  uses  a  fuel  percentage  of  10%  to  maintain  in  reserve. 
This  would  be  similar  to  a  set  mechanical  requirement  for  the  seawater  compensated  fuel 
system  onboard  DDG’s.  However,  if  the  CO  wants  to  maintain  reserve  stock  to  mitigate 
the  risk  of  running  out  of  fuel,  this  should  be  a  parameter  in  the  NFMS  model.  In  our 
next  scenario,  we  examine  the  effects  of  such  a  change.  In  this  case,  we  use  the  weather 
coefficients  on  the  links  from  nodes  1  to  2  and  nodes  4  to  5,  as  shown  in  Table  16  but 
increase  the  “percent  to  maintain”  to  30%,  as  shown  in  Table  18. 


Table  18.  Changing  fuel  percent  to  maintain  form  10%  to  30%. 
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Examining  Table  18,  it  can  be  seen  that  number  signs  appear  in  the  “least  fuel” 
cell.  This  signifies  that  the  shortest  path  solution  from  the  previous  example  is  no  longer 
valid  as  one  or  more  link  weights  now  exceed  the  maximum  fuel  (315,000  gallons) 
allowed  per  link.  Therefore,  the  solver  must  be  run  again,  given  the  user’s  input 
requirement  to  maintain  a  larger  fuel  reserve,  to  find  a  new  shortest  path  that  does  not 
violate  any  constraints.  The  results  can  be  seen  in  Table  19. 


Flows: 

To 

From 

N-1 

N-4 

N-9 

N-2 

N-3 

N-5 

N-6 

N-7 

N-8 

Flow  out 

Node  1 

0.0 

0.0 

0.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

Node  4 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

0.0 

0.0 

0.0 

1.0 

Node  9 

0.0 

o.or 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  2 

0.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

Node  3 

0.0 

o.or 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  5 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0  | 

0.0 

0.0 

1.0 

1.0 

Node  6 

0.0 

0.0 

0.0 

0.0 

0.0  1 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  7 

0.0 

0.0 

0.0 

0.0 

o.o  i 

0.0 

0.0 

0.0 

0.0 

0.0 

Node  8 

0.0 

0.0 

1.0 

0.0 

0.0  . 

0.0 

0.0 

0.0 

0.0 

1.0 

Flow  in 

0.0 

1.0 

1.0 

1.0 

0.0 

1.0 

0.0 

0.0 

1.0 

Gallons: 

To 

From 

N-1 

N-4 

N-9 

N-2 

N-3 

N-5 

N-6 

N-7 

N-8 

Node  1 

********* 

********* 

288,790 

****** 

Node  9 

Node  2 

Node  3 

Node  5 

Node  6 

Node  7 

Node  8 

288,790 

72,507 

21.968 

183,399 

109,548 

********* 

176,709 

311.908 

183.399 

109,548 

********* 

********** 

43,936 

179,303 

247,300 

146,861 

217,522 

146,861 

76,121 

217.522 

76,121 

Least  Fuel  =  I  854,328  I 


Fuel  Capacity  =  450,000  < -Fuel  Capacity  of  Ship  (variable  per  class) 

-e-'Cr"1:  :o  '~"j  :_i  "  = _ ? 0 ° 'c  (-Fuel  Percentage  to  maintain  onboard  can  set  to  mechanical  failure  or  CO  standing  orders 

Max  Fuel  Used  per  link  =  315,000 


Table  19.  Results  of  running  solver  with  weather  coefficients,  and  new  fuel 

percentage  requirement. 


Now  the  target  cell,  the  light  green  cell,  labeled  “least  fuel,”  has  a  solution  as 
denoted  by  the  yellow  highlighted  cells:  node  1  node  2  ->  node  4  ->  node  5  ->  node  8 
node  9.  The  new  optimal  fuel  plan  translates  to  Norfolk  ->  RAS  #2  ->  Mallorca  -> 
RAS  #5  RAS#8  Dubai.  This  is  the  same  solution  from  the  original  example  prior 
to  adding  the  weather  coefficients  with  the  same  least  fuel  amount  of  854,328  gallons. 
Therefore,  by  changing  the  “percent  to  maintain”  onboard  from  10%  to  30%  a  tradeoff 
has  occurred.  The  CO  now  knows  the  cost  to  mitigate  the  risk  of  running  out  of  fuel  is  an 
additional  15,726  gallons  of  fuel. 
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We  can  see  from  the  scenarios  presented  above  that  the  NFMS  provides  valuable 
tradeoff  analyses  unavailable  in  the  PIM  model.  The  ability  to  evaluate  and  compare 
alternative  plans  is  the  “value  added”  from  developing  a  decision  support  system  such  as 
NFMS.  Once  a  prototype  NFMS  has  been  implemented,  detailed  sensitivity  analyses 
(“what  if’  scenarios)  can  be  conducted,  possibly  in  conjunction  with  discrete  event 
simulation  models,  to  further  measure  the  benefits  of  NFMS.  This  is  a  promising  avenue 
for  future  research  efforts. 

F.  ADDITIONAL  CONSIDERATIONS 

There  are  over  200  ships  in  today’s  Navy.  If  each  ship  is  continually  rerunning 
fuel  plans  for  analysis,  daily  for  fuel  plans  in  operation  and  twice  daily  for  fuel  plans 
under  development,  this  may  result  in  a  large  processing  load  on  the  NFMS  CONUS 
server.  It  should  also  be  noted  that  the  example  used  for  the  proof  of  concept  is  a  simple 
static  one  to  demonstrate  how  NFMS  model  and  its  associated  shortest  path  algorithm 
can  work.  Once  the  FSMD  is  populated  with  all  the  possible  refueling  nodes,  the 
transportation  network  size  could  easily  reach  in  the  hundreds.  Using  Excel’s  linear 
programming  feature  is  not  going  to  be  an  efficient  technique  for  the  shortest  path  when 
hundreds  of  nodes  are  involved,  dynamically  changing,  on  a  given  transportation 
network.  By  using  the  dual  theorem,  Dijkstra’s  algorithm  can  be  used  to  achieve  the 
same  solution  in  a  much  more  efficient  way  [11],  and  should  be  used  as  the  baseline 
algorithm  for  NFMS. 

Even  using  Dijkstra’s  algorithm  to  increase  efficiency,  processing  time  may  be 
lengthy.  Although  Dijkstra’s  algorithm  runs  in  polynomial  time  (O(rT)),  where  n  is  the 
number  of  nodes  in  the  network)  a  large-preprocessing  time  is  needed  to  retrieve  and 
format  the  data  for  the  algorithm,  and  the  network  itself  may  grow  in  a  nonpolynomial 
fashion,  when  many  alternative  paths  exist.  Therefore,  priorities  should  be  assigned  to  the 
types  of  optimizations  being  calculated.  If  a  user  input  change  occurs  in  the  NFMS,  it 
should  be  given  top  priority  since  this  means  that  an  operational  fuel  plan  is  not  being 
followed  correctly,  and  thus,  more  fuel  has  been  burned  than  expected  or  the  ship’s 
operational  schedule  has  changed  and  the  fixed  port  visits  have  changed.  This  signals  an 
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unusual  occurrence  that  should  be  assigned  the  highest  priority,  since  a  ship  is  underway 
and  runs  the  highest  risk  of  running  out  of  fuel  and  has  an  urgent  need  for  a  new  fuel 
plan. 

Second-level  priority  should  be  given  to  the  24-hour  update  process,  where 
NFMS  checks  for  port  visit  changes  and/or  weather  changes  that  could  impact  the 
optimal  fuel  plan.  This  situation  is  where  the  most  gallons  of  fuel  can  potentially  be 
saved  in  the  long  run.  By  taking  advantage  of  following  seas,  avoiding  rougher  waters, 
and  discovering  new  optimal  fueling  locations,  a  more  efficient  path  can  be  followed. 
Routine  processing  should  be  used  for  planning  purposes  of  future  fuel  plans  not  in 
operation.  Since  these  ships  are  inport  and  planning  ahead  of  time,  a  delay  in  returning 
an  optimal  fuel  plan  is  acceptable  compared  to  the  risk  associated  with  the  other  two 
priorities. 

We  now  developed  and  defined  the  base  algorithm  at  the  heart  of  NFMS. 
Preprocessing  will  be  required  to  convert  the  units  given  to  the  link  weights  in  gallons  of 
the  transportation  network.  Microsoft  Excel  was  used  as  a  tool  to  solve  for  shortest  path. 
This  provided  a  means  to  do  a  sensitivity  analysis  changing  the  inputs  and  showing  the 
true  value  NFMS  can  be  to  the  fleet.  Finally,  since  NFMS  is  expected  to  be  highly 
utilized,  priorities  for  processing  should  be  established.  Next,  we  will  discuss  the  user 
interfaces  for  NFMS. 


65 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


66 


V.  USER  INTERFACES 


A.  GUI  INTERFACES 

The  user  interface  of  a  decision-support  system  application  is  a  critical  success 
factor  in  its  eventual  adoption.  The  intuitive  nature  of  the  interface  and  ease  of  use 
defines  the  usability  of  a  system,  and  its  continued  use  in  service.  Therefore,  the 
following  use-cases  and  associated  screen  captures  provide  some  insight  into  the  type  of 
intuitive  interfaces  NFMS  should  support. 

1.  Map-Based  Interfaces 

Since  NFMS  is  working  with  fuel  plans  for  ocean  voyages,  the  best  interface  to 
visually  describe  a  plan  is  a  map-based  interface.  This  interface  should  be  scalable, 
provide  a  legend  for  the  symbology  used,  and  use  a  granularly  shaded  line  to  depict  fuel 
percentages.  Figure  19  shows  a  mock-up  of  an  interface  using  Google  Earth  as  the 
background  for  the  plan. 


Figure  19.  Example  1  of  map-based  interface. 
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In  Figure  19,  it  can  be  clearly  seen  that  the  plan  entails  going  from  Cyprus  to 
Djibouti  to  Navy  Oiler  2  to  Bahrain.  This  track  is  shaded  from  green  to  yellow  to  depict 
fuel  percentage.  As  a  ship  follows  a  track,  its  fuel  will  be  depleted,  the  extent  to  which  is 
represented  by  the  color  of  the  track.  Each  time  the  track  intercepts  a  refueling  location, 
the  color  changes  from  its  current  status  to  green,  indicating  that  the  ship  has  refueled. 
Known  refueling  ports  in  the  area  are  represented  by  brown  squares,  and  RAS 
rendezvous  locations  with  oilers  by  gray  lines. 

Track  shading  should  be  based  on  the  refueling  percentage  onboard.  The  track 
color  should  be  displayed  as  solid  yellow  at  50%  or  less  of  the  difference  between  full 
refueling  and  the  amount  of  fuel  the  CO’s  decides  should  remain  onboard.  For  example, 
if  the  CO  wishes  to  always  maintain  30%  fuel  onboard,  then  the  line  should  turn  yellow 
at  50%  of  100%  to  30%  scale  or  65%  of  actual  fuel  onboard.  The  line  should  turn  solid 
red  when  fuel  is  estimated  to  reach  the  30%  level.  Once  the  fuel  reaches  below  the  safe 
to  operate  level  for  seawater  compensated  fuel  systems,  the  line  should  turn  black, 
indicating  that  the  ship  should  not  operate  beyond  that  point. 

Figure  20  represents  a  fuel  burn  chart  view  that  should  be  a  selection  from  the 
view  menu.  In  this  display,  the  amount  of  fuel  is  displayed  on  the  Y-axis  and  either 
increases  or  decreases  as  a  function  of  time  across  the  X-axis.  This  will  give  decision 
makers  another  way  of  determining  whether  they  are  on  track  with  the  current  plan,  or  if 
an  alternate  plan  needs  to  be  created. 
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Figure  20.  Notional  fuel  burn  chart  view  in  NFMS. 

2.  Text  Data  Input  Interface 

Inputting  a  large  amount  of  text,  especially  latitudes  and  longitudes,  can  be  a 
lengthy  endeavor;  however;  based  on  the  schema  described  in  Chapter  III,  the  amount  of 
text  entered  by  the  user  will  be  limited,  once  a  list  of  known  ports  is  established,  else  a 
latitude  and  longitude  for  each  fixed  waypoint  would  need  to  be  entered  each  time  a  new 
fuel  plan  request  is  made.  This  is  important  for  two  reasons: 

1.  The  more  users  are  required  to  input  numbers,  the  more  often  they  make 
mistakes,  which  can  compromise  the  system  with  incorrect  data  that,  in  turn, 
may  provide  the  decision  maker  invalid  results; 

2.  If  the  numbers  need  to  be  typed  in  manually  each  time,  that  is  extra 
information  that  must  be  transmitted  this  in  turn  consumes  bandwidth. 
Therefore,  when  a  user  adds  a  port  to  the  plan,  a  selection  box  populated  by 
the  known  port  database  should  be  available,  as  well  as  a  standard  calendar 
input  scheme,  so  the  user  does  not  mistakenly  input  the  incorrect  data.  An 
example  of  this  type  of  input  can  be  seen  in  Figure  2 1 . 
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Please  enter  the  information  about  the  Waypoint 
1 .  Enter  a  Waypoint 
|  Norfolk.  VA 


2.  Is  this  a  begining  point0  Begining  Percentage  3.  Is  this  an  ending  point0  Ending  Percentage 

r  Yes  No  f80%3 


r  Yes  ^  No  1 98% 
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Figure  2 1 .  Example  of  intuitive  text-based  interfaces. 


In  Figure  21,  the  interface  allows  beginning  and  ending  points  on  the  plan  to  be 
entered.  If  the  answer  is  “yes”  to  a  beginning  point,  then  the  calendar  and  time  input  for 
arrival  should  be  grayed  out  and  unavailable.  Likewise,  if  “yes”  is  selected  for  an  ending 
point,  then  the  calendar  and  time  for  departure  should  be  grayed  out  and  unavailable.  If 
the  answer  is  “no,”  then  the  percentages  should  be  grayed  out  and  unavailable.  The 
“percent  to  maintain”  over  the  entire  plan  should  be  entered  when  the  plan  is  sent  to  the 
CONUS  server. 
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B.  USE-CASE  DIAGRAMS 

Use-case  diagrams  provide  a  means  to  visually  describe  the  interaction  users,  or 
in  UML  tenninology,  actors  have  with  a  system.  The  following  use-case  diagrams  offer 
a  preliminary  starting  point  for  mocking  up  additional  GUI  views  and  the  eventual 
functionality  of  both  the  NFMS  and  FSMD. 


1.  NFMS  Use-Case  Diagram 


Figure  22.  NFMS  System  Level  Use-Case  diagram 


Figure  22  depicts  the  NFMS  system  use-case  diagram.  It  is  comprised  of  two 
actors,  a  user  and  administrator,  both  of  whom  are  required  to  login  to  the  system.  The 
information  flows  between  the  servers  have  been  described  in  Chapter  III.  Here,  the 
different  functionality  is  depicted  through  interfaces.  One  is  requesting  a  new  plan  that 
will  ultimately  involve  inputting  the  waypoint,  the  GUI  for  which  is  shown  in  Figure  21. 
If  the  waypoint  is  not  already  in  the  database,  then  the  user  will  need  to  request  a  new 
waypoint  be  entered.  Only  an  administrator  should  create,  update  and  delete  a  well- 
known  waypoint  from  the  system.  These  well-known  waypoints  are  the  fixed  waypoints 
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described  in  Chapter  III  and  the  fixed  nodes  in  the  transportation  network  described  in 
Chapter  IV.  The  user  can  also  view  a  plan  in  the  system  in  the  different  views  shown  in 
Figures  19  and  20.  Finally,  the  user  will  be  able  provided  updated  fuel  plan  variables  to  a 
plan  that  is  in  use,  as  described  in  Chapter  III. 


2.  FSMD  Use-Case  Diagram 


Figure  23.  FSMD  System  Level  Use-Case  diagram 


The  FSMD  is  an  important  part  of  the  NFMS  since,  without  it,  no  alternate 
refueling  waypoints  can  be  discovered.  Figure  23  depicts  some  of  the  user  interaction 
with  the  FSMD.  At  the  user  level  the  Port/RAS  addition,  removal,  or  change  should  be 
for  that  user’s  particular  port,  ports  in  a  region,  or  refueling  ship.  At  the  administrator 
level  the  addition,  removal,  or  change  in  a  schedule  can  be  system  wide  on  any  of  the 
ports  or  refueling  ships.  The  ports  in  a  region  would  be,  for  example,  where  the  5th  Fleet 
is  changing  the  availability  for  ports  within  the  AOR.  It  would  be  an  unnecessary  risk  to 
allow  the  commercial  port  itself  to  have  access  to  the  system  to  change  their  schedule. 
The  administrator  should  be  available  to  resolve  any  discrepancies  with  running  a  large 
database  application.  The  GUIs  and  use-cases  described  in  this  chapter  have  been  used  to 
show  the  look  and  feel  of  NFMS. 
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VI.  CONCLUSIONS 


A.  SUMMARY 

We  have  laid  out  a  detailed  requirements  analysis  for  an  NFMS  decision-support 
system  that  supports  the  refueling  planning  process.  Our  proof  of  concept  shows  that  the 
NFMS  can  optimize  refueling  plans  for  individual  Navy  ships,  while  providing  valuable 
decision-making  alternatives  in  the  form  of  tradeoff  analysis  not  available  in  the  current 
PIM  system.  One  of  the  major  benefits  of  the  NFMS  is  that  it  can  adapt  a  refueling  plan 
to  changes  in  the  weather  “on  the  fly,”  a  feature  beyond  the  capabilities  of  the  static  PIM 
approach.  This  results  in  more  efficient  usage  of  fuel  with  the  commensurate  benefit  of 
reducing  overall  fuel  usage  costs.  The  ability  to  factor  in  the  dimension  of  weather  also 
enhances  the  “realism”  of  the  decision  support  system.  By  providing  decision  makers 
with  the  ability  to  explore  alternate  scenarios,  it  strengthens  the  portfolio  of  choices  for 
building  refueling  plans.  Further,  the  NFMS  provides  a  tidy  circumscribed  test  bed  that 
could  be  used  as  a  training  environment  to  sharpen  planning  and  forecasting  skills. 

B.  RECOMMENDATIONS  AND  FUTURE  WORK 

We  have  detailed  requirements  for  an  NFMS  DSS  and  shown  how  this  could,  in 
principle,  be  implemented.  This  work  could  be  extended  in  many  interesting  ways,  a  few 
of  which  we  suggest  below. 

1.  Implementing  FSMD  and  NFMS  Prototypes 

A  full  implementation  of  an  NFMS  prototype  is  desirable  and  would  require,  in 
parallel,  the  development  of  a  detailed  FSMD  database.  Using  the  FNMOC  route 
generator  service  and  the  requirements  detailed  in  this  thesis  as  a  starting  point,  follow-on 
thesis  work  could  implement  prototypes  for  both  the  NFMS  and  FSMD.  These  efforts 
would  require  extensive  knowledge  of  a  database  system  such  as  Microsoft  Access™  or 
SQL  Server™,  XML,  Excel,  a  map-based  user  interface  (MUI)  and  a  programming 
language  such  as  Visual  Basic  to  coordinate  the  databases,  the  algorithms  and  the  MUI. 
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The  FSMD  can  be  prototyped  in  conjunction  with  the  NFMS  if  the  interfaces  are 
designed  prior  to  prototyping.  The  requirements  detailed  in  this  thesis  in  the  form  of  the 
tables  in  Chapters  III  and  IV  provide  a  strong  foundation  for  designing  and  developing 
the  database  schema  and  associated  tables. 

2.  Validation  of  the  Model  Using  Simulation 

Once  a  working  NFMS  has  been  developed,  detailed  validation  of  the  model  can 
be  conducted.  The  spreadsheet  optimization  engine  allows  for  many  “what  if’  scenarios 
involving  different  levels  of  “percent  to  maintain”  and  “GTG  burn  fuel  average”;  other 
adjustable  parameters  could  be  added  to  the  model  as  the  validation  procedure  unfolds. 
An  accompanying  discrete  event  simulation  could  be  developed  using  a  language  such  as 
Arena™  to  not  only  corroborate  the  results  of  the  optimization  model,  but  also  to  reveal 
possible  shortcomings  of  the  model,  as  well  as  opportunities  for  improvement  and 
refinement  of  the  model.  The  simulation  could  also  be  used  to  extend  the  scope  from  an 
individual  ship  toaCSGorESG. 

3.  Add  Cost  to  Fuel  Management  Database 

By  adding  cost  weights  to  the  different  refueling  points,  the  optimization  path  can 
reflect  not  only  the  most  fuel  efficient,  but  also  the  most  cost  efficient  routes  as  well.  For 
example,  the  weight  on  a  NATO  oiler  may  be  1  or  2  depending  on  the  price  per  barrel  of 
DFM.  However,  the  cost  of  pulling  into  port  at  Seychelles  could  be  as  large  a  multiplier 
as  9.  If  statistical  modeling  can  provide  accurate  weights  for  the  different  refueling 
points,  then  it  may  prove  to  be  less  fuel  efficient  to  go  to  the  NATO  oiler  first  than  to  pull 
into  Seychelles  and  not  refuel  inport.  This  would  be  different  from  the  most  fuel  efficient 
path  that  recommends  pulling  into  Seychelles  and  refueling  inport. 

4.  Scalability 

The  scenario  described  in  Chapter  IV  as  a  proof  of  concept  assumes  a  single  ship 
planning  its  voyage  across  the  ocean.  However,  ships  normally  deploy  within  a  Carrier 
Strike  Group  (CSG)  or  Expeditionary  Strike  Group.  These  CSG  and  ESG  can  and  do 
deploy  with  a  refueling  asset.  There  should  be  a  function  built  into  the  NFMS  that  allows 
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for  a  ship  to  be  deployed  with  a  CSG  or  ESG  and  manage  the  refueling  plan  at  a  higher 
level  where  the  Commodore  of  a  group  or  squadron  can  manage  refueling  plans  for  more 
than  one  ship  at  a  time. 

5.  Operational  Boxes  (OPBOX) 

As  stated  in  the  assumptions  for  this  thesis,  Navy  ships  do  not  always  follow  a 
straight  line  through  the  ocean  to  get  from  point  A  to  point  B.  At  times,  they  are  given  a 
wide  area  of  the  ocean  called  an  OPBOX  to  stay  inside  for  searching  and/or  monitoring 
purposes.  Inside  an  OPBOX,  a  ship  can  be  barely  moving,  may  have  a  search  pattern  to 
follow,  or  could  drive  for  winds  for  flight  operations.  Various  averages  of  fuel 
consumptions  should  be  gathered  based  on  ship  class  to  detennine  the  amounts  of  fuel 
expended  for  these  types  of  operations.  Using  this  data,  an  OPBOX  schedule  can  be 
generated  to  give  NFMS  a  way  of  estimating  the  fuel  burned  between  entering  an 
OPBOX  at  a  DTG  and  departing  an  OPBOX  at  a  DTG. 

NFMS  can  fill  a  gap  in  the  planning  process  for  Navy  decision  makers.  The 
current  method  of  determining  fuel  usages  is  based  on  historical  data  and  at  best  the  PIM 
model  that  is  inaccurate.  NFMS  will  be  able  to  accurately  predict  fuel  consumption  for 
Navy  ships,  a  great  benefit  to  the  planning  and  budgeting  process.  Then  NFMS  can 
optimize  the  plans  based  on  current  weather  conditions  or  dynamically  changing  ship 
schedules,  ensuring  that  ship  operate  within  their  budget.  Also,  since  refueling 
operations  will  go  from  periodic  to  planned,  more  time  can  be  spent  on  station  and 
overworked  crews  do  not  need  to  expend  extra  energy  needlessly  refueling. 

This  thesis  provides  future  areas  of  research  for  follow  on  theses.  Prototyping  the 
NFMS  and  its  interfaces,  modeling  and  prototyping  the  FSMD,  and  simulating  “what  if’ 
scenarios  using  the  Microsoft  Excel  tables  is  just  the  beginning. 
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